Consensus and Peer Services BIPs for the Segregated Data proposal.
Following on from discussion on DelvingBitcoin. Attempted to post for discussion on mailing list without success.
I've spent plenty of time trying to get it precise, hopefully there are no glaring errors. Happy to answer any further technical questions here or on the mailing list if directed.
Hi @MrHash, thank you for your submission.
Looking through the discussion at https://delvingbitcoin.org/t/bip-draft-segregated-data-a-prunable-script-isolated-block-region-for-data-carriage/2641/40, the feedback was extensive and entirely negative.
The first line of the README in this repository states: "People wishing to submit a BIP should first describe their idea to the bitcoindev@googlegroups.com mailing list to gather feedback on viability and community interest before working on a formal description." BIP3 also describes this in more detail. Please see the README and BIP 3 for the process.
In your PR description, you write, "Attempted to post for discussion on mailing list without success." When did you send your post? Sometimes it can take a fortnight or more for the mods to get through the queue and patience may be needed.
In summary, with negative community feedback in Delving, and with no discussion on the mailing list, this PR was opened prematurely, and it ought to see positive conceptual feedback from the community before opening a PR here. Let's close this for now.
@jonatack I attempted to start a discussion at the mailing list over 1 month ago but my submission was denied and i don't know why. I reached out to @RubenSomsen directly on socials to find out why but unfortunately didn't get a response.
Instead I created a conversation on Delving which seemed to be the only option at that point. There were several misunderstandings which were not followed on after I clarified. In the end, the useful technical feedback was fully taken on board and the BIPs have been updated in the last weeks into their current form which resolve the technical issues that were raised. Finally @murchandamus suggested I make the PR which I am now doing. Negative feedback seems to have been based on either opinion on economic principle or just plain misunderstanding, partly due to imprecision in explaination by me. I also had some brief conversations with @adam3us on X where he gave some technical suggestions and feedback which I have incoporated.
I've tried to follow the procedure but i've faced obstacles, and again here. I'd appreciate if you would re-open the PR for consideration properly, otherwise clear the barriers for me to post to the mailing list. In any case, negative opinion is not grounds alone for closing a technical proposal like this.
thanks
Murch suggested that I make the PR so that's what I did, because I had no idea if trying to send to the mailing list would be blocked again. I'm not trying to bother devs at all. The negativity on Delving revolved around a strange misconception that this allowed data carriage for free, which is 100% wrong. As I said, technical feedback was appreciated and the proposal fixed. Meanwhile i've been having entirely positive feedback from Adam Back on X.
I took the time just now to reach out to the ML mods.
One confirmed that your submission was not approved, more or less for not making sense and wasting the community's time.
Another mod replied that the discussion is already ongoing on delving, so it's better to continue the conversation there.
The negativity on Delving revolved around a strange misconception
technical feedback was appreciated and the proposal fixed
I would suggest continuing the existing discussion on Delving, with a link to the updated/fixed version on your GitHub. That said, none of the feedback I am seeing from any of the people involved is encouraging. Good luck.
From what it sounds like you are saying that if i try to submit a second time to the mailing list with the update proposal in order to reach a broader audience that it will be censored again?
@MrHash The mailing list tries for a balance in order to keep it useful and readable for experienced reviewers who have limited time. That review is the bottleneck, and you are asking for it repeatedly despite negative technical feedback from all of them so far. This has been a recurring problematic pattern in submission to the list and here. I've already suggested a way forward in my previous post.
@jonatack To be clear, i am not trying to waste the community's time. I'm trying to present a valid technical proposal which has been misunderstood at its surface. I have been instructed to make a PR and I attach the proof of proposed next steps.
<img width="774" height="215" alt="Screenshot 2026-07-27 at 23 42 36" src="https://github.com/user-attachments/assets/40df5f30-bc71-4cb3-a671-ed8720a07a69" />
I also attach a screenshot of Dr Back promoting the proposal after review:
<img width="595" height="371" alt="Screenshot 2026-07-27 at 23 49 39" src="https://github.com/user-attachments/assets/dcf412f2-08e4-4546-9048-509afe2f6392" />
There is more detailed proposal discussion here: https://x.com/adam3us/status/2075619857714856354 and https://x.com/adam3us/status/2071164137569145207
Given that clearly you can see there is significant and useful positive feedback, I would kindly ask that you stop treating this or my following of the procedure as a waste of community time, but as a serious albeit unusual and unfamiliar proposal from outside the existing Core team.
FWIW, this updated proposal does not appear to make any more sense than the previous one that saw only negative technical feedback on Delving, and I see why the mail list mods did not accept it.
The newer proposal would make data optional at every depth and keep consensus validation identical, fixing the reorg risk AJ Towns described. Nodes would only check a commitment plus the declared size against the weight limit; everything else would be policy.
It would be a soft fork for something that doesn’t need consensus rules. One can already commit to arbitrary data hashes today. The data still consumes block weight even though no one is required to keep or serve it. Most nodes would ignore it, making availability unreliable. Use cases that care about permanence would stick to normal witness or OP_RETURN data.
It would be adding protocol complexity for a feature most nodes will turn off and that has weak incentives to be used at all.
Some of the best reviewers in the space were in that Delving discussion and I believe you received generous feedback there that is as expert as you'll see and need.