Skip to content

ELIP 202: Implementation of optional sidechain peg-in subsidy and minimum peg-in amount#1499

Merged
psgreco merged 6 commits into
ElementsProject:masterfrom
delta1:pegin-subsidy
Feb 9, 2026
Merged

ELIP 202: Implementation of optional sidechain peg-in subsidy and minimum peg-in amount#1499
psgreco merged 6 commits into
ElementsProject:masterfrom
delta1:pegin-subsidy

Conversation

@delta1

@delta1 delta1 commented Oct 22, 2025

Copy link
Copy Markdown
Member

Implementation for ELIP 202

@delta1 delta1 added the hacktoberfest-accepted Accepted for participation in Hacktoberfest. label Oct 28, 2025
@tomt1664 tomt1664 self-requested a review January 12, 2026 16:52
tomt1664
tomt1664 requested changes Jan 14, 2026
View reviewed changes
Comment thread src/init.cpp Outdated
@tomt1664 tomt1664 self-requested a review January 14, 2026 17:17
@tomt1664

tomt1664 commented Jan 14, 2026

Copy link
Copy Markdown
Member

minor nit: mix of "pegin" and "peg-in" in documentation and error messages.

tomt1664
tomt1664 reviewed Jan 14, 2026
View reviewed changes
Comment thread src/validation.cpp
@jsarenik

jsarenik commented Jan 15, 2026 •
edited
Loading

Copy link
Copy Markdown

Currently I run a pruned Elements node on liquidv1 with the default validatepegin setting of 1. Reading the ELIP sounds like it will not be possible when the new options get enabled because getrawtransaction on my pruned Bitcoin node will return the transaction merely while it is in the mempool (which can happen to be mined into a block before Elements node notices the transaction). IMHO it's asking for a race condition.

I don't like the idea of the main chain Bitcoin transaction fee influencing the amount getting burned on liquidv1 during peg-in (after being enabled, of course, but adding the possibility now into the code just begs for enabling it eventually).

Concept ACK now as I did not know the context.

Edit: I see the reasoning now thanks to explanation from Pablo.

@tomt1664

tomt1664 commented Jan 15, 2026

Copy link
Copy Markdown
Member

Tested ACK 7353687

@delta1

delta1 commented Jan 15, 2026

Copy link
Copy Markdown
Member Author

Rebased to remove the fixup commit - sorry to invalidate your ACK @tomt1664

@psgreco

psgreco commented Jan 15, 2026

Copy link
Copy Markdown
Contributor

Currently I run a pruned Elements node on liquidv1 with the default validatepegin setting of 1. Reading the ELIP sounds like it will not be possible when the new options get enabled because getrawtransaction on my pruned Bitcoin node will return the transaction merely while it is in the mempool (which can happen to be mined into a block before Elements node notices the transaction). IMHO it's asking for a race condition.

I don't like the idea of the main chain Bitcoin transaction fee influencing the amount getting burned on liquidv1 during peg-in (after being enabled, of course, but adding the possibility now into the code just begs for enabling it eventually).

Concept NACK

I may be misunderstanding something of course so please help me understand ELIP 202 if you see anything in what I write.

In order for a claim to work, the tx needs to be at least 100 blocks deep, so that is unaffected.
The idea behind using the bitcoin feerate as a reference is to make the tx generation deterministic and independent on the fee rate at the moment of submitting the claim.

@delta1

delta1 commented Jan 15, 2026

Copy link
Copy Markdown
Member Author

@jsarenik

Currently I run a pruned Elements node on liquidv1 with the default validatepegin setting of 1. Reading the ELIP sounds like it will not be possible when the new options get enabled because getrawtransaction on my pruned Bitcoin node will return the transaction merely while it is in the mempool (which can happen to be mined into a block before Elements node notices the transaction). IMHO it's asking for a race condition.

Do you mean with validatepegin=0? Even so, you can still compose the peg-in transaction with subsidy correctly by passing the parent (bitcoin) transaction feerate to claimpegin or createrawpegin if/when this change is ever active on liquidv1.

I don't like the idea of the main chain Bitcoin transaction fee influencing the amount getting burned on liquidv1 during peg-in (after being enabled, of course, but adding the possibility now into the code just begs for enabling it eventually).

As the Liquid Federation drives the tech roadmap for liquidv1, it's their prerogative should they want this enabled to subsidise or discourage low value peg-ins that they must pay for on the mainchain to sweep or spend.

Concept NACK

Noted.

I may be misunderstanding something of course so please help me understand ELIP 202 if you see anything in what I write.

It may be worth reading it again.

delta1 added 6 commits January 15, 2026 18:10
@delta1
DecomposePeginWitness: fix deserialization flags for MerkleBlock proof
f3b63f4 
In CreatePeginWitnessInner, the MerkleBlock is always serialized without
witness: PROTOCOL_VERSION | SERIALIZE_TRANSACTION_NO_WITNESS

In DecomposePeginWitness before this change, the MerkleBlock was
deserialized with witness: PROTOCOL_VERSION

This was only noticed as an issue in the pegin subsidy implementation,
in a failure in the feature_dynafed functional test. In the
test_transition_mempool_eject test case, the Merkle block proof is coming
from the same chain where we are creating a pegin.

See the comment: "hack: since we're not validating peg-ins in parent chain,
just make both the funding and claim tx on same chain (printing money)"

I haven't investigated enough to explain why this causes a
deserialization failure in this specific case, but presumably this change
is correct since we're always serializing without witness. Before this
DecomposePeginWitness was only used in src/psbt.cpp
@delta1
subsidy: add chainparams and init
94cde59
@delta1
subsidy: implementation for claimpegin, createrawpegin, and RPCs
51c89c6
@delta1
validation: check for peg-in subsidy and minimum
186bb25
@delta1
test: add pegin subsidy functional test
90b2b3b
@delta1
grammar: prefer peg-in to pegin in messages
a18a88b
@delta1

delta1 commented Jan 15, 2026

Copy link
Copy Markdown
Member Author

Rebased against master

@jsarenik

jsarenik commented Jan 15, 2026

Copy link
Copy Markdown

Concept NACK

Noted.

Thank you. I have changed my mind already.

It may be worth reading it again.

I did. But still I would suggest adding some context (maybe a link if it was discussed anywhere). I am not in any office, nor a Telegram channel now, to hear any first-hand gossip from people. And it could be interesting in the future to have an idea about the things happening at the time. Of course no one wants to add wood to fire but misunderstandings like this can happen exactly when there is missing context I'd say.

Thank you for resolution, @delta1 !

@jsarenik

jsarenik commented Jan 15, 2026

Copy link
Copy Markdown

Runnung a18a88b with one-liner here-uncommitted change of tweakfedpegscript making my build dirty but seen on each Liquid block at https://anyone.eu.org/liquid/gi.txt

Running ACK a18a88b

@tomt1664

tomt1664 commented Jan 16, 2026

Copy link
Copy Markdown
Member

Tested ACK a18a88b

@jsarenik jsarenik mentioned this pull request Feb 8, 2026
Open
@psgreco psgreco merged commit 7791d31 into ElementsProject:master Feb 9, 2026
14 checks passed
delta1 added a commit to delta1/elements that referenced this pull request Feb 12, 2026
@delta1
Merge 7791d31 into merged_master (Elements PR ElementsProject#1499)
9e5aaef
psgreco added a commit to psgreco/elements that referenced this pull request Mar 12, 2026
@psgreco
Revert "Merge ElementsProject#1499: ELIP 202: Implementation of optio…
87b72b8 
…nal sidechain peg-in subsidy and minimum peg-in amount"

This reverts commit 7791d31, reversing
changes made to 6bb916a.
delta1 added a commit that referenced this pull request Mar 13, 2026
@delta1
Merge #1537: Prepare 23.3.3rc2
2262381 
fa01ad2 Update manpages (Pablo Greco)
cc2dd3c Bump version to 23.3.3-rc2 (Pablo Greco)
87b72b8 Revert "Merge #1499: ELIP 202: Implementation of optional sidechain peg-in subsidy and minimum peg-in amount" (Pablo Greco)
56eb713 Log status of ELIP 203 (Pablo Greco)
d805236 liquidv1: allow enabling -acceptunlimitedissuances (Pablo Greco)
bd59321 contrib: upstream my merge-prs.sh changes (Byron Hambly)
a18a88b grammar: prefer peg-in to pegin in messages (Byron Hambly)
90b2b3b test: add pegin subsidy functional test (Byron Hambly)
186bb25 validation: check for peg-in subsidy and minimum (Byron Hambly)
51c89c6 subsidy: implementation for claimpegin, createrawpegin, and RPCs (Byron Hambly)
94cde59 subsidy: add chainparams and init (Byron Hambly)
f3b63f4 DecomposePeginWitness: fix deserialization flags for MerkleBlock proof (Byron Hambly)

Pull request description:

  Updates master to c990492, which adds support for enabling ELIP 203 in liquidv1, but with  ELIP 202 reverted. Also and bumps version/manpages

ACKs for top commit:
  delta1:
    ACK fa01ad2; tested locally, diff as expected
  tomt1664:
    Tested ACK fa01ad2

Tree-SHA512: b84da4948d72a638a107868a89676387ec4154e53f3e3c8b937db4cba022819945d49e3f9630c3d6c4574fe32ae8931cc8088374a02229ea027c9f50c487008c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@tomt1664 tomt1664 tomt1664 approved these changes

Assignees

No one assigned

Labels

hacktoberfest-accepted Accepted for participation in Hacktoberfest.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@delta1 @tomt1664 @jsarenik @psgreco