Speedy trial support for versionbits #21377

ajtowns · 2021-03-06T09:21:39Z

BIP9-based implementation of "speedy trial" activation specification, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html

Edge cases are tested by fuzzing added in #21380.

evoskuil · 2021-03-06T10:21:58Z

+1

jonatack · 2021-03-06T12:06:51Z

Concept ACK

michaelfolkson · 2021-03-06T12:41:32Z

Concept ACK

roconnor-blockstream · 2021-03-06T14:14:14Z

I take it that this PR doesn't preclude also migrating to BIP8-style height based activation?

benthecarman · 2021-03-06T14:56:24Z

I take it that this PR doesn't preclude also migrating to BIP8-style height based activation?

Concept ACK but would much rather have height based activation

src/test/versionbits_tests.cpp

JeremyRubin · 2021-03-06T16:35:38Z

Concept ACK.

It does seem like there is a preference for height based activation as opposed to time.

i'd further request that -- to the extent this is getting BIP'd, that the activation date must not be within the range of the provided interval or we introduce some other sort of quantization / min interval parameter (e.g., every 3 block-months there is a new-rule activation window and we use the next one, or the activation blocks is something like current + max(2016*N, earliest - current).

michaelfolkson · 2021-03-06T16:48:49Z

I don't know (though I can guess) why people are trying to refer to BIP 9 now instead of BIP 8, especially as height based activation seems the superior option.

As a reminder, there have been community IRC meetings (which many Core contributors attended and disclosed their views) where there was broad consensus on using revised BIP 8 e.g. http://gnusha.org/taproot-activation/2021-02-02.log

Rusty's conclusion post that meeting was "Unanimous support for BIP 8. RIP BIP 9."

The outline of the various proposals used BIP 8 rather than BIP 9: https://en.bitcoin.it/wiki/Taproot_activation_proposals

And various media articles reporting on the discussion referred to BIP 8 rather than BIP 9.

Though I don't expect it to scupper the momentum this promising proposal is generating if people want to call this BIP 9 (or do mental gymnastics by opening a new BIP) please be clear on why it doesn't fit within the template of BIP 8.

Other than that, I am delighted with the progress this proposal is making and having a PR up in such quick time really is great, so many thanks for your work on this.

edit: Thinking about this more I don't think it would be mental gymnastics to open a new BIP for "Speedy trial" especially if it doesn't fit cleanly into a more flexible BIP 8. New BIP or more flexible BIP 8. BIP 9 is dead and if "Speedy trial" could be used for other soft forks it shouldn't be included in the Taproot BIPs.

roconnor-blockstream · 2021-03-06T16:57:04Z

I believe the best way to proceed would be to rebase a BIP8-height PR on top of this PR. Once this PR is merged, we have the ability to produce an acceptable set of parameters for speedy trial. If then the subsequent BIP8-height PR is merged afterwards then we get, what I believe to be, a superior set of activation parameters, but if the BIP8-height subsequent PR fails for whatever reason, that is okay.

I'm anticipating test cases added to this PR that would in turn be valuable for the BIP8-height PR, and the BIP8-height speedy trial will need an analogous activation_height field as well.

DrahtBot · 2021-03-06T18:35:04Z

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

Refactor versionbits deployments to avoid potential uninitialized variables #21401 (Refactor versionbits deployments to avoid potential uninitialized variables by achow101)
Replace unused BIP 9 logic with draft BIP 8 #19573 (Replace unused BIP 9 logic with draft BIP 8 by luke-jr)
common: Disallow calling IsArgSet() on ALLOW_LIST options #17783 (util: Fix -norpcwhitelist, -norpcallowip, and similar corner case behavior by ryanofsky)
refactor: Remove settings merge reverse precedence code #17581 (refactor: Remove settings merge reverse precedence code by ryanofsky)
refactor: Add ALLOW_LIST flags and enforce usage in CheckArgFlags #17580 (refactor: Add ALLOW_LIST flags and enforce usage in CheckArgFlags by ryanofsky)
util: Forbid ambiguous multiple assignments in config file #17493 (util: Forbid ambiguous multiple assignments in config file by ryanofsky)

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.

JeremyRubin · 2021-03-06T19:36:25Z

@roconnor-blockstream that sounds like one reasonable plan of attack -- merging this now is a concrete step, patching to use height can occur independently. I do fear there would not be consensus on a non-height based activation proposal, so it may be important to not rest on laurels for accepting those changes.

Making the case for BIP8 merge first then these changes, the BIP8 code is much more reviewed presently (with no code nacks, just conceptual ones?) and it may be a better utilization of developer time to rebase this onto BIP8.

I think it would be best to hear from @luke-jr and @ajtowns on their preference as they seem to be primary contributors on the implementation/review of both.

benthecarman · 2021-03-06T20:35:03Z

Once this PR is merged, we have the ability to produce an acceptable set of parameters for speedy trial. If then the subsequent BIP8-height PR is merged afterwards

This seems dangerous as we could have people compile and start running after the activation params are merged, merging a following change to the params could cause people to be running different activation logic (one time based, one hieght based).

roconnor-blockstream · 2021-03-06T20:48:07Z

@benthecarman. Not to worry this PR doesn't have activation parameters in it. I would expect merger of activation parameters to be delayed until after a BIP8-height PR is done consideration.

That being said, I've chatted a bit with @achow101 and it may be the case that a BIP8-min-activation-height PR ends up being easier to implement as a stand alone PR rather than on top of this one. There are issues with merging, and backporting etc. So I'm going to stop myself from further back-seat deving and let the pros figure out the best way to hammer out PRs.

ajtowns · 2021-03-06T22:17:39Z

Making the case for BIP8 merge first then these changes, the BIP8 code is much more reviewed presently (with no code nacks, just conceptual ones?) and it may be a better utilization of developer time to rebase this onto BIP8.

I don't think the BIP8 code is adequately reviewed yet -- we had an off-by-one bug that would have left lot=true and lot=false nodes out of consensus found this past week, that wasn't discovered by reviewers or the automated tests. (Currently it isn't a clean merge either)

The main benefits of bip8 are lockinontimeout=true related -- that it specifies the option at all, and that it's height based, so loss of hashpower (due to miners preferring a chain that is invalid according to lockinontimeout=true) doesn't reduce the number of retarget periods available for activation. So I don't think there's any real benefits to doing this via bip8 rather than bip9 as far as the "Speedy trial" itself goes; but if bip8/height based code is thoroughly reviewed and ready to merge prior to setting activation parameters, that seems fine too as far as I can see.

michaelfolkson · 2021-03-06T22:34:29Z

I don't think the BIP8 code is adequately reviewed yet -- we had an off-by-one bug that would have left lot=true and lot=false nodes out of consensus found this past week, that wasn't discovered by reviewers or the automated tests.

@ajtowns: Are you referring to a bug Sjors found in the tests? That is hardly a consensus bug for LOT=true and LOT=false nodes on mainnet but you are right to say it wasn't yet ready to be merged. I have since recommended it be closed as some have expressed that they would not merge it with any LOT code (even if dead code).

ajtowns · 2021-03-06T23:05:04Z

@michaelfolkson No, that one wasn't a bug. I'm referring to this one.

harding · 2021-03-07T05:27:45Z

Concept ACK. Thank you, @ajtowns! I'm happy to see that the change really is minimal.

Do I understand correctly from reading the code that activation will occur in the first block of the next retarget period after the activation_time? E.g., if the minimum activation time just passed but the height is 1234, the first block where taproot's rules are enforced still won't be until height 2016? That seems fine to me for the sake of code simplicity, but it does mean that, if it looks like activation_time is going to fall near a retarget block, we'll have to communicate that taproot could either happen tomorrow or two weeks from now. Maybe to avoid that communication challenge, it'd be better to use a height?

@michaelfolkson

I don't know (though I can guess) why people are trying to refer to BIP 9 now instead of BIP 8, especially as height based activation seems the superior option.

As mentioned in my email, I thought basing the proposal on the existing BIP9 code in Bitcoin Core (as done in this PR) would be the smallest change and so fastest to get reviewed, merged, and released. Since the goal of the Speedy Trial proposal is speed (with safety), that seems highly advantageous to me.

I completely agree that using block heights for the start and timeout parameters has advantages for this proposal (giving miners a known number of signaling periods) and that, as also mentioned in my email, getting BIP8 included in the code now would have advantages if Speedy Trial fails and we decide to use BIP8 as originally imagined for a follow-up activation attempt.

My preference would be for whatever solution is most preferred by reviewers.

ghost · 2021-03-07T14:37:38Z

concept ACK.

Sjors · 2021-03-07T16:51:20Z

src/chainparams.cpp

@@ -80,7 +80,7 @@ class CMainParams : public CChainParams {
        consensus.nPowTargetSpacing = 10 * 60;
        consensus.fPowAllowMinDifficultyBlocks = false;
        consensus.fPowNoRetargeting = false;
-        consensus.nRuleChangeActivationThreshold = 1916; // 95% of 2016
+        consensus.nRuleChangeActivationThreshold = 1815; // 90% of 2016


Maybe add a note here to never change this unless all soft forks are burried. Alternatively maybe we should have a separate variable for this speedy trial.

Can be fixed (in a follow-up refactor) with commit 2be730c + commit 50eb7f0

Sjors · 2021-03-07T17:19:39Z

Concept ACK for speedy trial support. However I'm not convinced we should permanently drop the BIP9 threshold to 90%.

@JeremyRubin wrote:

merging this now is a concrete step, patching to use height can occur independently

I'm fine with a height based approach too; slightly more code changes, but it seems easier to communicate when things happen. I also agree with Jeremy's point. Nothing here is set in stone until we actually apply it to Taproot (or another soft fork).

There is one downside though, in addition to more review work: other implementations probably already have BIP 9 code ready to go. Although compared to implementing all of Taproot this is not a big deal (and without implementing Taproot they can't verify the new consensus rules anyway).

Making the case for BIP8 merge first then these changes, the BIP8 code is much more reviewed presently (with no code nacks, just conceptual ones?)

For me that's only an option if the LOT=true stuff is stripped from that PR.

It doesn't seem terribly complicated to cherry-pick 9762562, bcec418 (though I suggest a fresh BIP for the speedy trial) and a few more.

Sjors · 2021-03-07T17:25:10Z

src/consensus/params.h

@@ -29,6 +29,8 @@ struct BIP9Deployment {
    int64_t nStartTime;
    /** Timeout/expiry MedianTime for the deployment attempt. */
    int64_t nTimeout;
+    /** If lock in occurs, delay activation until at least this time. */
+    int64_t activation_time;


We could add reduced_threshold which, if non-zero, overrides nRuleChangeActivationThreshold.

I think we can worry about genericity if we ever need to add 2 simultaneous vbit releases... which I've heard rumor not too many people think we'd be likely to ever do that (although I think it is fine)

IIUC with the latest change, nRuleChangeActivationThreshold is only used for the "the might be an unknown rule change" warning system. Each deployment now has its own threshold.

See also 9e50401 which in addition lowers the warning threshold even further.

ajtowns · 2021-03-08T02:58:15Z

but it does mean that, if it looks like activation_time is going to fall near a retarget block, we'll have to communicate that taproot could either happen tomorrow or two weeks from now.

I think it's worse than that -- if activation_time falls very near a retarget block, I think you could have the eleven last blocks of the retarget period have timestamps (relative to activation_time) like: -3000, -2400, -1800, -1200, -600, 0, 600, 1200, 1800, 2400, 3000 giving the last block a median time which satisfies MedianTimePast() >= activation_time, so the next block would switch to ACTIVE and people would likely start transacting with taproot, perhaps even racing to get a tx in the first block as some did with segwit, and setting nlocktime to ensure their transaction isn't mined early and the funds stolen.

However in that case a 2 block reorg could change the last block's timestamp to -400 (still greater than the mediantime of the prior block which is likely -600), which would change its median time from 0 to -400, which would then cause the new first block of the next period to still be in state LOCKED_IN. At that point replaying the taproot-using transactions people had sent prior to the reorg would allow funds to be stolen as taproot is not yet active after the reorg, and nlocktime would not have protected you.

(EDIT: fixed mediantime rules misinterpretation -- blocks must have a timestamp greater than the previous block's mediantime; block's mediantime does include their own timestamp. And add the following...)

I think the conclusion from this is just "the height at which you transition from LOCKED_IN to ACTIVE must be fully determined as soon as you transition from STARTED to LOCKED_IN". That way the entire LOCKED_IN period has to be reorged if you want to steal funds protected by both nlocktime and the new rules.

ajtowns · 2021-03-08T03:27:32Z

Bumped to min_activation_height instead of activation_time; also helps github notice that #21334 already merged.

Sjors · 2021-03-08T09:38:04Z

Shameless plug for #19013 which adds backwards compatibility testing for v0.21; this should be useful when testing soft fork deployment.

JeremyRubin · 2021-03-08T20:28:16Z

based on the reasoning here: https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3658078 I have very limited concerns around using start/stop times (could be wrong)

@ajtowns that's a great point -- MTP just has ambiguity baked into it, and we should prefer heights for the activation point.

Github-Pull: bitcoin#21377 Rebased-From: dd85d54

Github-Pull: bitcoin#21377 Rebased-From: dd07e6d

Previously we used deployments that would timeout prior to Bitcoin's invention, which allowed the deployment to still be activated in unit tests. This switches those deployments to be truly never active. Github-Pull: bitcoin#21377 Rebased-From: 55ac5f5

This removes the DEFINED->FAILED transition and changes the STARTED->FAILED transition to only occur if signalling didn't pass the threshold. This ensures that it is always possible for activation to occur, no matter what settings are chosen, or the speed at which blocks are found. Github-Pull: bitcoin#21377 Rebased-From: f054f6b

Github-Pull: bitcoin#21377 Rebased-From: ffe33df

Github-Pull: bitcoin#21377 Rebased-From: dd85d54

Github-Pull: bitcoin#21377 Rebased-From: dd07e6d

Previously we used deployments that would timeout prior to Bitcoin's invention, which allowed the deployment to still be activated in unit tests. This switches those deployments to be truly never active. Github-Pull: bitcoin#21377 Rebased-From: 55ac5f5

This removes the DEFINED->FAILED transition and changes the STARTED->FAILED transition to only occur if signalling didn't pass the threshold. This ensures that it is always possible for activation to occur, no matter what settings are chosen, or the speed at which blocks are found. Github-Pull: bitcoin#21377 Rebased-From: f054f6b

Github-Pull: bitcoin#21377 Rebased-From: ffe33df

fanquake · 2021-04-16T00:28:49Z

Being backported in #21701.

Github-Pull: bitcoin#21377 Rebased-From: dd85d54

Github-Pull: bitcoin#21377 Rebased-From: dd07e6d

Previously we used deployments that would timeout prior to Bitcoin's invention, which allowed the deployment to still be activated in unit tests. This switches those deployments to be truly never active. Github-Pull: bitcoin#21377 Rebased-From: 55ac5f5

This removes the DEFINED->FAILED transition and changes the STARTED->FAILED transition to only occur if signalling didn't pass the threshold. This ensures that it is always possible for activation to occur, no matter what settings are chosen, or the speed at which blocks are found. Github-Pull: bitcoin#21377 Rebased-From: f054f6b

Github-Pull: bitcoin#21377 Rebased-From: ffe33df

jaybny · 2021-04-16T03:47:02Z

ACK - no need for BIP8 at this time

cbd64c3 Add mainnet and testnet taproot activation params (Andrew Chow) ec78243 chainparams: drop versionbits threshold to 90% for mainnnet and signet (Anthony Towns) 6003573 versionbits: simplify state transitions (Anthony Towns) 3acf037 versionbits: Add explicit NEVER_ACTIVE deployments (Anthony Towns) b529222 fuzz: test versionbits delayed activation (Anthony Towns) 71917e0 tests: test versionbits delayed activation (Anthony Towns) 4cab84c versionbits: Add support for delayed activation (Anthony Towns) f9517e6 tests: clean up versionbits test (Anthony Towns) 1c01645 tests: test ComputeBlockVersion for all deployments (Anthony Towns) 2e9e7f4 tests: pull ComputeBlockVersion test into its own function (Anthony Towns) Pull request description: Backport of #21377 and #21686 ACKs for top commit: instagibbs: cherry-pick ACK cbd64c3 jnewbery: ACK cbd64c3 Sjors: tACK cbd64c3 MarcoFalke: cherry-pick-only ACK cbd64c3 🌾 Tree-SHA512: e9efb0ca9986d685161bcba5ed43efdc5f1dca88322cf65faccf17009b567c2d930c2aba4d1541539fc65347574ed4faa3d4558b907c779d1c128b3d2c681f31

This allows to remove check that windows for the same bit are disjoint This addresses bitcoin#21377 (comment)

* bitcoin#21377 (comment) * bitcoin#21377 (comment)

This allows to remove check that windows for the same bit are disjoint This addresses bitcoin#21377 (comment)

* bitcoin#21377 (comment) * bitcoin#21377 (comment)

fjahr · 2021-04-17T18:21:47Z

Post merge Code Review ACK ffe33df

Also built and ran unit tests locally.

Kixunil

Not reviewed, just confused, sorry for the noise.

harding · 2021-04-18T17:15:42Z

src/chainparams.cpp

-        consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nTimeout = 1230767999; // December 31, 2008
+        consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nStartTime = Consensus::BIP9Deployment::NEVER_ACTIVE;
+        consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nTimeout = Consensus::BIP9Deployment::NO_TIMEOUT;
+        consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].min_activation_height = 0; // No activation delay


@Kixunil The activation parameters were add in a separate PR, #21686

This allows to remove check that windows for the same bit are disjoint This addresses bitcoin#21377 (comment)

* bitcoin#21377 (comment) * bitcoin#21377 (comment)

DrahtBot added Consensus Validation labels Mar 6, 2021

ghost reviewed Mar 6, 2021

View reviewed changes

src/test/versionbits_tests.cpp Outdated Show resolved Hide resolved

DrahtBot mentioned this pull request Mar 6, 2021

Convert taproot to flag day activation #21378

Closed

ajtowns mentioned this pull request Mar 7, 2021

tests: Add fuzzing harness for versionbits #21380

Merged

Sjors reviewed Mar 7, 2021

View reviewed changes

ajtowns force-pushed the 202103-bip9-speedy-trial-support branch from d614299 to cb5f1a2 Compare March 8, 2021 03:25

achow101 pushed a commit to achow101/bitcoin that referenced this pull request Apr 15, 2021

tests: test versionbits delayed activation

0bcbc0b

Github-Pull: bitcoin#21377 Rebased-From: dd85d54

achow101 pushed a commit to achow101/bitcoin that referenced this pull request Apr 15, 2021

fuzz: test versionbits delayed activation

31862e0

Github-Pull: bitcoin#21377 Rebased-From: dd07e6d

achow101 pushed a commit to achow101/bitcoin that referenced this pull request Apr 15, 2021

chainparams: drop versionbits threshold to 90% for mainnnet and signet

563d349

Github-Pull: bitcoin#21377 Rebased-From: ffe33df

achow101 mentioned this pull request Apr 15, 2021

[0.21] Speedy trial activation for Taproot #21701

Merged

achow101 pushed a commit to achow101/bitcoin that referenced this pull request Apr 15, 2021

tests: test versionbits delayed activation

032ef33

Github-Pull: bitcoin#21377 Rebased-From: dd85d54

achow101 pushed a commit to achow101/bitcoin that referenced this pull request Apr 15, 2021

fuzz: test versionbits delayed activation

46fb713

Github-Pull: bitcoin#21377 Rebased-From: dd07e6d

achow101 pushed a commit to achow101/bitcoin that referenced this pull request Apr 15, 2021

chainparams: drop versionbits threshold to 90% for mainnnet and signet

c409ad7

Github-Pull: bitcoin#21377 Rebased-From: ffe33df

fanquake removed the Needs backport (0.21) label Apr 16, 2021

achow101 pushed a commit to achow101/bitcoin that referenced this pull request Apr 16, 2021

tests: test versionbits delayed activation

71917e0

Github-Pull: bitcoin#21377 Rebased-From: dd85d54

achow101 pushed a commit to achow101/bitcoin that referenced this pull request Apr 16, 2021

fuzz: test versionbits delayed activation

b529222

Github-Pull: bitcoin#21377 Rebased-From: dd07e6d

achow101 pushed a commit to achow101/bitcoin that referenced this pull request Apr 16, 2021

chainparams: drop versionbits threshold to 90% for mainnnet and signet

ec78243

Github-Pull: bitcoin#21377 Rebased-From: ffe33df

maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Apr 17, 2021

test: Check that no versionbits are re-used

6666213

This allows to remove check that windows for the same bit are disjoint This addresses bitcoin#21377 (comment)

maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Apr 17, 2021

test: Address outstanding versionbits_test feedback

fa772dc

* bitcoin#21377 (comment) * bitcoin#21377 (comment)

maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Apr 17, 2021

test: Check that no versionbits are re-used

fad4167

This allows to remove check that windows for the same bit are disjoint This addresses bitcoin#21377 (comment)

maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Apr 17, 2021

test: Address outstanding versionbits_test feedback

faec1e9

* bitcoin#21377 (comment) * bitcoin#21377 (comment)

Kixunil reviewed Apr 18, 2021

View reviewed changes

windsok pushed a commit to windsok/bitcoin that referenced this pull request Apr 23, 2021

test: Check that no versionbits are re-used

a2dddfd

This allows to remove check that windows for the same bit are disjoint This addresses bitcoin#21377 (comment)

windsok pushed a commit to windsok/bitcoin that referenced this pull request Apr 23, 2021

test: Address outstanding versionbits_test feedback

3d52125

* bitcoin#21377 (comment) * bitcoin#21377 (comment)

glozow mentioned this pull request Dec 21, 2021

Newsletters: add 180 (2021-12-22) bitcoinops/bitcoinops.github.io#702

Merged

bitcoin locked and limited conversation to collaborators Oct 30, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Speedy trial support for versionbits #21377

Speedy trial support for versionbits #21377

ajtowns commented Mar 6, 2021 •

edited

Loading

evoskuil commented Mar 6, 2021

jonatack commented Mar 6, 2021

michaelfolkson commented Mar 6, 2021

roconnor-blockstream commented Mar 6, 2021

benthecarman commented Mar 6, 2021

JeremyRubin commented Mar 6, 2021

michaelfolkson commented Mar 6, 2021 •

edited

Loading

roconnor-blockstream commented Mar 6, 2021

DrahtBot commented Mar 6, 2021 •

edited

Loading

JeremyRubin commented Mar 6, 2021

benthecarman commented Mar 6, 2021

roconnor-blockstream commented Mar 6, 2021

ajtowns commented Mar 6, 2021

michaelfolkson commented Mar 6, 2021 •

edited

Loading

ajtowns commented Mar 6, 2021

harding commented Mar 7, 2021

ghost commented Mar 7, 2021

Sjors Mar 7, 2021 •

edited

Loading

maflcko Mar 24, 2021 •

edited

Loading

Sjors commented Mar 7, 2021 •

edited

Loading

Sjors Mar 7, 2021

JeremyRubin Mar 8, 2021

Sjors Mar 9, 2021

Sjors Mar 9, 2021

ajtowns commented Mar 8, 2021 •

edited

Loading

ajtowns commented Mar 8, 2021

Sjors commented Mar 8, 2021

JeremyRubin commented Mar 8, 2021

fanquake commented Apr 16, 2021

jaybny commented Apr 16, 2021

fjahr commented Apr 17, 2021

Kixunil left a comment •

edited

Loading

This comment was marked as resolved.

harding Apr 18, 2021

Speedy trial support for versionbits #21377

Speedy trial support for versionbits #21377

Conversation

ajtowns commented Mar 6, 2021 • edited Loading

evoskuil commented Mar 6, 2021

jonatack commented Mar 6, 2021

michaelfolkson commented Mar 6, 2021

roconnor-blockstream commented Mar 6, 2021

benthecarman commented Mar 6, 2021

JeremyRubin commented Mar 6, 2021

michaelfolkson commented Mar 6, 2021 • edited Loading

roconnor-blockstream commented Mar 6, 2021

DrahtBot commented Mar 6, 2021 • edited Loading

Conflicts

JeremyRubin commented Mar 6, 2021

benthecarman commented Mar 6, 2021

roconnor-blockstream commented Mar 6, 2021

ajtowns commented Mar 6, 2021

michaelfolkson commented Mar 6, 2021 • edited Loading

ajtowns commented Mar 6, 2021

harding commented Mar 7, 2021

ghost commented Mar 7, 2021

Sjors Mar 7, 2021 • edited Loading

Choose a reason for hiding this comment

maflcko Mar 24, 2021 • edited Loading

Choose a reason for hiding this comment

Sjors commented Mar 7, 2021 • edited Loading

Sjors Mar 7, 2021

Choose a reason for hiding this comment

JeremyRubin Mar 8, 2021

Choose a reason for hiding this comment

Sjors Mar 9, 2021

Choose a reason for hiding this comment

Sjors Mar 9, 2021

Choose a reason for hiding this comment

ajtowns commented Mar 8, 2021 • edited Loading

ajtowns commented Mar 8, 2021

Sjors commented Mar 8, 2021

JeremyRubin commented Mar 8, 2021

fanquake commented Apr 16, 2021

jaybny commented Apr 16, 2021

fjahr commented Apr 17, 2021

Kixunil left a comment • edited Loading

Choose a reason for hiding this comment

This comment was marked as resolved.

harding Apr 18, 2021

Choose a reason for hiding this comment

ajtowns commented Mar 6, 2021 •

edited

Loading

michaelfolkson commented Mar 6, 2021 •

edited

Loading

DrahtBot commented Mar 6, 2021 •

edited

Loading

michaelfolkson commented Mar 6, 2021 •

edited

Loading

Sjors Mar 7, 2021 •

edited

Loading

maflcko Mar 24, 2021 •

edited

Loading

Sjors commented Mar 7, 2021 •

edited

Loading

ajtowns commented Mar 8, 2021 •

edited

Loading

Kixunil left a comment •

edited

Loading