GM all. Can anyone recommend a quality foss self hosted BTC blockchain explorer? I trust you all more than google. Thanks.

Idk if mempool.space is foss

But it is os

Dang. TIL.

We’re live right now 🐸https://x.com/emblemvault/status/1798014565365792886?s=46&t=VKlzOqs5vqDWcDUEI3d16w

Does anyone have an opinion on fulcrum vs electrs to share?

Fulcrum probly your only option if you’re using windows

Debain, about to nuke and restart with Ubuntu

I’m playin with electrs.

Works fine, and decoupling it from core makes sense. It can be kept as an interface though, like mempool does

https://mempool.space/docs/faq#address-lookup-issues

Spoke too early 😆. Looking back at the core code the integration with addrindrs is already implemented like an interface. It used to be indexd.

The same could be done with electrs I think

A pair of interesting (and good IMO) news.

First is that removing the hardcoded burns produces the same hashes! And the code is already in place, so it was just about deleting lines that adjusted the control flow.

Second, and the best news, is that I was able to fully replace addrindexrs with a vanilla electrs!

This is awesome because it means there is no need to maintain a separate fork! And it is already proven to be 100% compatible because I got a node to sync fully and the hashes match.

The patched library (core) code is here.

https://github.com/jotapea/counterparty-core/commits/master/

I’ll rework and clean it up for the next release. But it is interesting as is too, as the thought process (including some mistakes that were fixed) can be appreciated.

Electrs was on my mind, wondering if it could help save counterwallet too. Great job.

Thank you! I won’t make any promises, but maybe at the current state it could be possible to revive it by bypassing counterblock completely. That is the only way I would do it

updating to 10.2.0

wish me luck please

one question, where is this supposed to change??

forget... bitcoin.conf

has anyone already updated?

Running on one node. looking great.

any changes to stamp indexer required with this update?

I’ll do it soonish, and will apply the same patches (plus rps).

The CNTRPRTY version will continue being the “don’t trust, verify” one (without any hardcoded values), which I believe is a good thing to maintain

Not that I know of yet. The prior api is maintained and fixed even for the multiple get_blocks pagination bug.

https://j-dog.net/archive/XcpDevChat/

wow

scary

But why?

Dev question, Has anyone ever/Can you open a dispenser and include a OP_CHECKLOCKTIMEVERIFY so that the dispenser can not be closed until the lock expires?

I think there’s an unwritten rule that while this is technically a public chat it’s regarded as semi-private. Scraping it and publishing it on the web without even prior notification is a bad look imo.

Agreed

Agreed

If I delete my history in the chats would be deleted there or maintained?

Maintained

LOL

European Union wants a word with that domain

I have not authorized him to publish my conversation I'm taking with a known number of persons, without having at least known who is reading it

Phew

Yes

Thank you for the heads up… feels weird

I’ll pay pepe cash to anyone who has a copy of the pepeproject chat log showing my one comment and subsequent /p rolls that pissed off gmoney enough to ban me in January of last year, the same day the ETF’s went live.

Eh, if the discussion involves a public and open source protocol I think all discussions should be public. Maybe backing up chats is good just in case someone deleted it all

Lol

I’ve had admins bulk delete my chat history in multiple chats multiple times but I think I’m still in the logs

That's your opinion, if I want to delete my messages I'm in my right of doing it

reserving my opinion but I will say if a chat has a hidden history for new joins this really disrespects that

I just don't understand the rationale for @BrrrGuy storing/serving them

fbi

You’re speaking in a public channel, about a public decentralized protocol, and you expect that your messages will be kept private….. even though telegram has a full history of every message ever said, which anyone can dump, if they have the skill set.

I’m sorry that you feel it is a violation of your privacy to post things that you said publicly in public chat.

There are a number of private chats (rare pepe scientists, stamps dev, xcp devs, etc.) which have been archived and have NOT been made public specifically because the expectation is that they would always be private since they are private channels .

This is a public channel. No different than someone taking a video of you speaking on the street.

I felt it was important to document history, including all of the conversations around counterparty development, all the accusations, all of the development, conversations, etc.

I find it very interesting interesting that people are more concerned about their messages being logged rather than taking note that conversation in all of the development chats dropped off dramatically since the new development has started.

More development, less conversations🤷🏻‍♂️

It is unfortunate that some people would prefer that their in public areas stay private.

Perhaps in the future, remember that public chats are just that…. public 👍🏻

The telegram archive bot only dumps messages which are visible in the public channel…. I.e. if a Messages is deleted like spam or user or an admin delete the message….. The message is not visible.

You could easily verify this by checking the message number next to each message and see that indeed the message number jumps sometimes …. Those jumps and numbers indicate messages which have been deleted.

The bot only archives what is publicly available at the time when the archive is created… so no, you’re deleted messages are not shown, if they are deleted before the time the archive is made

If message history is hidden upon join, then those messages would not be available for the bot to archive 🤷🏻‍♂️

The archive is no different than someone going into Telegram scrolling up and taking screenshots of everything …. All the data is publicly available👍🏻

"The archive is no different than someone going into Telegram scrolling up and taking screenshots of everything"

100% agree, which doesn't make it less cringe 😁

anyway, my question was why you considered it necessary

which was replied here 👍

There seems to be a concerted effort to whitewash history and pretend things happen that didn’t …. I’m proud of my history and counterparty and felt it was important to document many of the conversations, for historical purposes.

This is just another step in me, archiving my history with counterparty, so I can close the door on this chapter, and step away and focus on other things now. 👍🏻

I think majority of the people here has been specially focused on moving forward. Not on looking or judging to the past, but that's just my opinion.

I think everyone here is focused on moving forward. Having an accurate log of what was said over the years related to counterparty development should not threaten moving forward.

The two are not mutually exclusive 🤷🏻‍♂️

Now back to lurking 👍🏻

Btw… lil known fact… one doesn’t even need to be in a channel to log a public channels archive🤷🏻‍♂️

Is the fact of archiving not the visibility or accesiibility to those conversations (as I agree they are readable by anyone), what brings the (at least for me at first instance) uncomfort

"There are a number of private chats (rare pepe scientists, stamps dev, xcp devs, etc.) which have been archived and have NOT been made public specifically because the expectation is that they would always be private since they are private channels."

Is like saying "I could post screenshots of private conversations but I'm not going to do it", of course everybody can do it, the fact of saying it is what makes it uncomfortable, is like stating the decission of making them public can change (again, just an opinion)

I don't have a problem with the open chats, I have the same or less filter in twitter, just expressing how it felt at first to see one conversation in one platform posted into a different platform 😛

No threats have been made. I simply highlighted the fact that private conversations will remain private, as there was some concern expressed by Mike that private conversations could be made public.

Just because I’m no longer involved in counterpart does not mean I’ve lost my integrity…. I would hope after years of serving the community that I could at least be given the benefit of the doubt🤷🏻‍♂️

Now I’m off to my son’s third grade graduation. I hope you guys get out and touch some grass today as well.❤️

Congrats on the graduation and enjoy sir 👏

Bro said🗣🗣 🌊🌊🗣🗣🌊

Shit I was looking forward to a monologue or something

It's not in his words but in his silences

Deleted from existence

Where is this gem? Public url?

https://j-dog.net/archive

There is a difference between right and poor form IMO
Does the 'right' exist to duplicate public corespondance, sure.
Is it good form to do so? Probably not and likely breaks some GDPR rule or something.
Will it adversely effect communications across the Counterparty ecosystem?

Is it petty, childish, and bratty? Well we already know there is a 'take-my-toys-and-play-elsewhere' mindset, not to mention the liberal use of socks so this is unlikely to be prevented.

Not the whole truth, a curated version.

I wish this person the best in their future endeavors as well as hope they find an outlet for the spiteful actions and childish behavior that goes against everything all of us were utilizing the network for.

In Europe It is illegal if you are a company or chat user, but if you are the government, it is okay to archive conversations and mantain it public.

The whole point of archiving, the logs across multiple chat rooms was to provide the whole truth… not a curated version…. But you believe whatever you want, man.

I wonder how long it would take to read it all

bro you're fine.

😁😁😁

I’m tiring of keeping up with your socks.

Well, in my defense, I was removed from this channel… so was necessary in order to keep up with what was being said about counterpart development since I was still the core developer at the time that I was removed.

Chat history documents this….. but I wouldn’t expect you to let facts get in the way of a good narrative👍🏻

This should not be controversial: the current state of Counterparty Dev is that the founders returned and consolidated control… To focus on many long overdue fixes and optimizations to the codebase and stack. All without breaking protocol.

As a first step, which is honorable.

But, that doesn’t mean is a free pass to the next protocol changes, if this is supposed to be a decentralized protocol (just mentioning it as a possibility, not accusing).

In the past I was calling this kind of broad control of channels (“power”) with Jeremy also. So I think I’m being consistent.

But big picture, I’m grateful for the current “core team” work. I’m benefiting from it, and others should do the same.

https://github.com/CounterpartyXCP/counterparty-core/issues/1939

LFG!

V11.11.0 like a g

getting this error randomly running v 10.2.0:
2024-06-26T10:15:59.871793000+00:00 - [ DEBUG] - API Status Poller - Backend state check passed.
2024-06-26T10:16:00.529612000+00:00 - [ INFO] - Block 849548
2024-06-26T10:16:00.678535000+00:00 - [ INFO] - Block 849548 - Closing dispenser for FAKEASF at 1BnERLy3 in 5 blocks (6149a37) [valid]
2024-06-26T10:16:00.679321000+00:00 - [ INFO] - Block 849548 - Parsing complete. L: 3f7e1cf, TX: ead4d6a, M: 5b81746 (0.15s)
2024-06-26T10:16:00.679847000+00:00 - [ DEBUG] - Cleaning mempool...
2024-06-26T10:16:02.276788000+00:00 - [ DEBUG] - Parsing 100 raw transactions from mempool...
ERROR:root:SQLITE_LOG: abort at 56 in [INSERT INTO transactions (tx_index, tx_hash, block_index, block_hash, block_time, source, destination, btc_amount, fee, data) VALUES (:tx_index, :tx_hash, :block_index, :block_hash, :block_time (2067) SQLITE_CONSTRAINT_UNIQUE
2024-06-26T10:16:02.286706000+00:00 - [ ERROR] - Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/follow.py", line 194, in handle
await self.receive_multipart(self.zmq_sub_socket_sequence, "sequence")
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/follow.py", line 188, in receive_multipart
self.receive_message(topic, body, seq)
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/follow.py", line 179, in receive_message
self.receive_sequence(body)
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/follow.py", line 158, in receive_sequence
mempool.parse_mempool_transactions(self.db, self.mempool_block)
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/mempool.py", line 33, in parse_mempool_transactions
mempool_tx_index = blocks.list_tx(
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/blocks.py", line 865, in list_tx
ledger.insert_record(db, "transactions", transaction_bindings, "NEW_TRANSACTION")
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/ledger.py", line 27, in insert_record
cursor.execute(query, record)
File "src/cursor.c", line 169, in resetcursor
apsw.ConstraintError: ConstraintError: UNIQUE constraint failed: transactions.tx_hash

2024-06-26T10:16:02.286925000+00:00 - [ INFO] - Stopping blockchain watcher...
2024-06-26T10:16:02.287560000+00:00 - [ INFO] - Stopping API Server...
2024-06-26T10:16:03.290625000+00:00 - [ INFO] - Stopping telemetry daemon...
2024-06-26T10:16:03.314229000+00:00 - [ INFO] - Stopping API Status Poller...
2024-06-26T10:16:03.378745000+00:00 - [ INFO] - Stopping API Server v1...
2024-06-26T10:16:03.621577000+00:00 - [ INFO] - Stopping blockchain watcher...
2024-06-26T10:16:03.622483000+00:00 - [ INFO] - Closing database connections...
2024-06-26T10:16:03.647736000+00:00 - [ INFO] - Stopping AddrIndexRs thread...
2024-06-26T10:16:03.648029000+00:00 - [ DEBUG] - AddrindexRS Client - Server: `172.17.0.3:8432` - Disconnected
2024-06-26T10:16:04.631772000+00:00 - [ INFO] - Shutting down logging...
2024-06-26T10:16:04.633022000+00:00 - [ INFO] - Stopping fetcher...
2024-06-26T10:16:04.633863000+00:00 - [ INFO] - Shutdown complete.

Prolly should ask the founders directly in the public channel CP channel... since they have chosen to leave this channel of developers where conversations happen... and instead force all conversations to github... yay "community" project 😂

I have asked them but was wondering if more node operators have faced that issue too

I’m not running v10.2

It has been crickets over there for a month. It’s a shame to see the development community conversation come to a screeching halt.

Does anyone know who keyuno is? They have some interesting viewpoints.

Has anyone (other than core devs) signed off on the security aspects and potential data leakage involved with node telematics?

I only know keyuno from GitHub, would be cool to have him in this chat.

And i am not as interested in engaging with the “official” repo after I was blocked. And I’m fine with it.

I'll talk with protocol changes, as i will need to upgrade infra.

And the CNTRPRTY core is disabling telematics

https://github.com/CounterpartyXCP/counterparty-core/milestone/23

Was going to make a cips/forum discussion about this, but may be better to just start here more casually.

Based on the current description, I am not on board.

#3 is not specific. #2 says is to be able to get rid of addrindexrs, which has been proven to be possible already.

Then for #1… I haven’t changed my opinion. Read: https://github.com/CounterpartyXCP/counterparty-core/issues/1814#issuecomment-2130151943

Hi Juan

Thank you for taking the time to respond and share this info and links.

I look forward to reading them and I'll get back to you if I have more questions or feedback.

Welcome to the developers end of the xcp rabbit hole. I’ve seen you around. Do you have any unanswered dev questions? What do you think?

https://github.com/CounterpartyXCP/counterparty-core/pull/1928

As an infra provider I was clear of the advantages of the v9 DB design. A single DB that provided good READ performance for steady state (following the tip).

v10 went all in on block parsing. Which has some merit… but now look at the added complexity that is bringing…

Which is a great reference btw, so from that perspective is positive.

But in my view it also validates that v9 is still a great alternative.

And I don’t see why it couldn’t be kept in parity with protocol changes in v10… some extremely easy like removing subasset fees.

It’s kind of funny because isn’t that like re-implementing counterparty for the api which is what everyone was doing before and they were like why are you idiots doing that

Classic

😂