Skip to content

Instantly share code, notes, and snippets.

View editor-Ajian's full-sized avatar

editor-Ajian

64 followers · 16 following
View GitHub Profile
@editor-Ajian
editor-Ajian / My concern on the recent change of `Bitcoin Core` ‘s OP_RETURN policy.md
Last active June 23, 2025 11:43
start with a thought experiment

Recently, PRs going to change Bitcoin Core's default OP_RETURN policy raised quite a controversy. You may guess I am opposing this change and you are right. I have not expressed my ideas anywhere as I always wait for better arguments from advocates (of course it is also waiting for learning and convincing). Maybe it is too late, as one of the PRs have been merged, however, I want to leave something , as least for myself.

Before that, let me make some other words: seriously taking this topic requires us to give up unfounded accusations towards certain developers and opinion expressers, their relating interests and personal motivations (in fact it is necessary for every serious debate). These accusations do not mean any valid arguments, neither for advocates nor for opponents. This post is not for anyone seeking these accusations. AND I will not name anyone in this post.

There are two PRs relevant: (1) PR#32359, which remove the relay policy code enforcing OP

@editor-Ajian
editor-Ajian / A design for MuSig2-adaptor-based PTLC in LN.md
Last active December 31, 2024 02:17

This post introduces a combination of MuSig2 with Signature Adaptors to enable PTLC (Point-Time-Locked-Contract) in LN channels, which is explicitly rely on option_simple_update.

In the process, I thought I find two things less being discussed:

  1. When combining signature adaptors with MuSig2 (-like aggregated signatures), the offer of a PTLC must get the partial signature of the receiver in advance, otherwise he have no guarantee to be able to extract the secret from the final aggregated signature. See the "A note about combining MuSig2 with signature adaptors" section.
  2. Using aggregated signatures to enforce PTLC doesn't allow us to leverage the SIGASH_SINGLE|SIGHASH_ANYONECANPAY trick, results in sub-optimal (even unacceptable) fee payment schemes (including the one in this design).

However, after I finish this work, (with some of my friends' help) I find that they ware already discovered by at least two authors. The first problem is found by, e.g. instagibbs[^11] and t-bast[^13]. The second probl