Skip to content

Instantly share code, notes, and snippets.

View instagibbs's full-sized avatar

Gregory Sanders instagibbs

618 followers · 0 following
View GitHub Profile
@instagibbs
instagibbs / ctvcsf.md
Last active June 10, 2025 13:16

CTV + CSFS Letter

Sorry, this got very long at least for my standards.

I'd like to start off by saying I believe that Bitcoin is in good technical hands regardless of how this shakes out. Good things take time and we've learned a lot; let's continue doing so.

Before I dive into what I think needs to be answered for this proposal to move forward, I'd like to respond to language in the letter to make sure we're on a common understanding of the asks being given here.

We respectfully ask Bitcoin Core contributors to prioritize the review and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or similar) within the next six months. We believe this timeline allows for rigorous final review and activation planning.

@instagibbs
instagibbs / op_return.md
Last active June 12, 2025 19:35

Caveat Emptor

I (instagibbs) was asked to draft a statement, I feel this is a fair summation of the project's direction. I might be wrong

Retiring the 80-Byte OP_RETURN Limit

Bitcoin Core’s next release will, by default, relay and mine transactions whose OP_RETURN outputs exceed 80 bytes and allow any number of these outputs. The long-standing cap, originally a gentle signal that block space should be used sparingly for non-payment proof of publication data, has outlived its utility.

@instagibbs
instagibbs / coredev_study.md
Last active January 16, 2025 16:23

L2/Covenants Coredev Study Group

Who is (potentially) leading: Somsen, instagibbs, ???

Who attends: Anyone invited to Coredev

Time/Location: FIXME Adam Jonas

Before we meet again at Coredev in late February, a few of us thought it would be helpful to organize a study club, aimed at you, Bitcoin Core contributors,

@instagibbs
instagibbs / sym_clrt.md
Last active January 15, 2025 19:03
Sketch of joining smart contracts through history proofs

Assume for simplicity contract id == txid of kickoff tx.

"register" == where we store committed state, can be CCV, caboose, whatever

kickoff tx has two outputs. These outputs, or the descendant of the first output and the second output MUST be spent together on the second spending path.

output 1 has a spk HISTORY_SPK which:

  1. self-replicates spk in new output (for simplicity)
@instagibbs
instagibbs / clrt.md
Last active January 2, 2025 14:17
Contract-level Relative Timelock (CLRT) UTXO for Eltoo

Contract-level Relative Timelock (CLRT) UTXO for Eltoo

Eltoo constructs such as ln-symmetry suffer from an issue where every time an update transaction is confirmed on the blockchain, the relative timelock is reset. This causes further funds lockup, and further extends HTLC expiry in the LN use-case, potentially reducing network utility.

How can we have a "contract" level relative timelock?

@instagibbs
instagibbs / cov_rationale.md
Last active March 5, 2025 20:05
Covenants Table Rationale

Non-exhaustive thoughts but better to have something written than nothing at all:

WANTING: There's no developer or larger community consensus on anything, so I marked anything I'm happy with as "Wanting" instead.

MEVil: The below discussion is predicated on the fact we as a community are no longer overly concerned with script enhancements creating mining centralization risk via MEVil.

OP_CTV

SIGHASH_ALL emulation. Pretty understandable how to use, also not very exciting on its own unless you believe it's the step function in usability for Arg, Timeout Trees, and also believe those are game changers. It does show up in a lot of places are cleanups removing interactivity in protocols, especially when combined with OP_CSFS.

@instagibbs
instagibbs / gist:cb1f7cfbd0a70e8b5393e457c7a959e6
Created November 21, 2024 17:37
diff --git a/test/functional/mining_basic.py b/test/functional/mining_basic.py
index fb649c1a6b..fe0cc5fa42 100755
--- a/test/functional/mining_basic.py
+++ b/test/functional/mining_basic.py
@@ -54,11 +54,16 @@ def assert_template(node, block, expect, rehash=True):
assert_equal(rsp, expect)
class MiningTest(BitcoinTestFramework):
def set_test_params(self):
@instagibbs
instagibbs / LN and mempool notes
Created September 25, 2024 03:06
28.0
----
a) Do nothing
- 1P1C things propagate better
- package rbf can often happen in non-adversial settings
b) disable update_fee
- 1 sat/vbyte static commit tx fee
- no commit tx format changes
@instagibbs
instagibbs / gist:058f51587074187cb78f5f9b9327442e
Created September 12, 2024 16:12
| ns/op | op/s | err% | total | benchmark
|--------------------:|--------------------:|--------:|----------:|:----------
| 93,062,810.00 | 10.75 | 0.3% | 1.02 | `LinearizeOptimallyExample00`
| 97,757,782.00 | 10.23 | 10.0% | 1.03 | :wavy_dash: `LinearizeOptimallyExample01` (Unstable with ~1.0 iters. Increase `minEpochIterations` to e.g. 10)
| 72,062,906.00 | 13.88 | 18.7% | 1.39 | :wavy_dash: `LinearizeOptimallyExample02` (Unstable with ~1.9 iters. Increase `minEpochIterations` to e.g. 19)
| 70,236,537.00 | 14.24 | 8.2% | 0.96 | :wavy_dash: `LinearizeOptimallyExample03` (Unstable with ~1.3 iters. Increase `minEpochIterations` to e.g. 13)
| 24,690,481.40 | 40.50 | 13.4% | 1.07 | :wavy_dash: `LinearizeOptimallyExample04` (Unstable with ~4.2 iters. Increase `minEpochIterations` to e.g. 42)
| 31,282,472.67 | 31.97 | 16.3
@instagibbs
instagibbs / gist:56a5d2cb289d06cd05122c7d525cea04
Created February 6, 2024 15:49
fast lane
Given the general resistance of people to concept ACK a specific
transaction topology like V3, I was thinking it would be useful
to think ahead and see what policy relaxations or restrictions
we could enact in the future to make things more flexible,
incentive compatible, and overall more useful.
TL;DR: V3 is useful and likely upgradeable to something
we can be more proud of.
Here are some ideas on what path we could take. Here's a set