aaaand kickstart sync just finished in 18 hours 🤯

What's your latest message?

so after sync is complete you have to restart bitcoind and then run counterparty-server start. bitcoind is syncing now, will lyk

Block: 836806 (78.52, hashes: L:42b24 / TX:e747c / M:d6e9b)

@ffmad

The code must still be changed in CP core. since the version is set in the config as 4.4.

https://t.me/Counterparty_Dev/12034

Thx. What's your latest message index?

{
"api_limit_rows": 1000,
"bitcoin_block_count": 836812,
"db_caught_up": true,
"indexd_blocks_behind": 0,
"indexd_caught_up": true,
"last_block": {
"block_hash": "00000000000000000002f1fa1bc0e7be942eaae25792c2d2b4bf87aa5d342314",
"block_index": 836812,
"block_time": 1711727376,
"difficulty": 83126997340024.61,
"ledger_hash": "6d9815f077dd407fe62bdb10cf8f0fedb5596f251ab8b7f46ab1aef6d4b32950",
"messages_hash": "bf65e2cca8ac18a79b5f9a79e05fec55993b42cfa3148d21b7dc550f71bc01ea",
"previous_block_hash": "00000000000000000000e5964d427a37fc46779b72830352c89f46a60e26d043",
"txlist_hash": "cc10224af18ecbebf5bae1287fc04d9b82a397579cfd25cbdec7f782cae7ac8d"
},
"last_message_index": 13601811,
"running_regtest": false,
"running_testcoin": false,
"running_testnet": false,
"server_ready": true,
"version_major": 10,
"version_minor": 0,
"version_revision": 0
}

{
result: {
server_ready: true,
db_caught_up: true,
bitcoin_block_count: 836817,
last_block: {
block_index: 836817,
block_hash: '0000000000000000000013534b956b0f32b3f9e6b347ce3261ee0c28e4b6d045',
block_time: 1711729283,
previous_block_hash: '0000000000000000000178c587232d0e74dfd8b9df213882a32e4c888c741300',
difficulty: 83126997340024.61,
ledger_hash: 'a1448a855f83e9d695224cb4c946bbe6698277ff02dfd315fc6f4fd716d6882e',
txlist_hash: 'fc167c082c048157d0c958c5bfb52ac52b1125a984e269bef2e4932b803c4a34',
messages_hash: '69848fdf0f1cff8642d05027d739c4c74788a3c6234481fa66b1750f490ec636'
},
indexd_caught_up: true,
indexd_blocks_behind: 0,
last_message_index: 5138694,
api_limit_rows: 1000,
running_testnet: false,
running_regtest: false,
running_testcoin: false,
version_major: 10,
version_minor: 0,
version_revision: 0
},
id: 0,
jsonrpc: '2.0'
}

you have `"last_message_index": 13601811,`

13,6m // 5,13m

that's weird

4.4.6 is newest addrindexrs. Core lib checks for 4.4.4 which is why we both changed it.

I noticed some of the change log notes for 4.4.5 and 4.4.6 make use of standard bitcoin.conf options, great idea to standardize those options. Similar thoughts applied to counterparty will address the previous issue with nonstandard bitcoind installs having blocks located in a different directory while counterparty can not find the bitcoind chainstate directory location.

I very much have responsibilities outside of the internet and counterparty. I find telegram works for me for now. I will gladly join github at a later date and contribute there, once I get a node running and as I find free time to volunteer.

Thanks for the help so far.

yeah idk. asking.

Does the develop branch read me/install section need any different instructions, commands or considerations?

Yeah just following on the conversations from here it seems the docs don’t have full instructions to get to a successful install

It would probably be helpful to have others check what they are getting

ANN When Counterparty was originally created, we launched with a working codebase + protocol on day one. I never wrote a whitepaper, because I thought it wasn't necessary. But ten years later, I think it will potentially help a lot of people to have a formal description of the project and protocol to refer to. So I went ahead and wrote a whitepaper for Counterparty—https://krellenstein.com/adam/

Have you checked other synchronized CP status?

I haven't. This isn't for me to say but strictly speaking messages aren't consensus critical so @teysol not sure what makes sense here...

This is weird that we have something that different

yes as I said looking into it.

Read it and I (99%) agree with it. I’m happy to see where we are today. The potential was there but the development state was sooo different just a couple of years ago.

So why 99%? I think the VM implementation will need more discussion with the community… Personally I would like to know the specifics of the use cases before being convinced this is a better path than just not dealing with any of it at all.

@ffmad what version are you running

Of Counterparty core?

yes. what does counterparty-server --version return

counterparty-server v10.0.0-beta.1; counterparty-lib v10.0.0-beta.1

V10.0.0-beta.1 for me too.

To get a node running without docker, should I…
1. Wait for/install a new counterparty version compatible with adr 4.4.6?

2. Delete addrindexrs 4.4.6 and install addrindexrs 4.4.4?

3. rm -rf /*

Git checkout develop

Already on ‘develop’
Your branch is up to date with ‘origin/develop’.

Can the “VM” be like a special broadcast that executes a programming language, like a JavaScript module exporting a single function. Then whatever is the outcome, translates to cp native messages like send, dividends, etc.. maybe even issuances

ah nope, that would not work at all

Ok then how would it work? Any simple example

can i join utxos?
i have 0.1 xcp in address 1
then i have 0.4 xcp in addres 2
so i want to send 0.5 xcp...

can I build the opreturn utxo with the amount 0.5 xcp?

0ac4baedcb92526aac4b71bc615e9e1b536f08a4b825cd09ca25118ade07a164

i just tested it dont work...

Getting this error

File "/usr/local/lib/python3.10/dist-packages/counterpartylib/lib
/check.py", line 274, in consensus_hash
raise ConsensusError(error_message)
counterpartylib.lib.check.ConsensusError: Incorrect txlist_hash has
h for block 823000. Calculated 3017c21e05aca875854fbe707aa9694771f
76bb768a064f290f017814fcec1bd but expected 53dd28b40d7ba79479445857
0fb880b108f9bc255f77721da128ac06f2e96e94
Unhandled Exception
Traceback (most recent call last):
File "/usr/local/bin/counterparty-server", line 8, in <module>
sys.exit(server_main())
File "/usr/local/lib/python3.10/dist-packages/counterpartycli/__i
nit__.py", line 20, in server_main
server.main()
File "/usr/local/lib/python3.10/dist-packages/counterpartycli/ser
ver.py", line 227, in main
server.start_all(catch_up=args.catch_up)
File "/usr/local/lib/python3.10/dist-packages/counterpartylib/ser
ver.py", line 541, in start_all
blocks.follow(db)
File "/usr/local/lib/python3.10/dist-packages/counterpartylib/lib
/blocks.py", line 835, in follow
new_ledger_hash, new_txlist_hash, new_messages_hash, found_mess
ages_hash = parse_block(db, block_index, block_time)
File "/usr/local/lib/python3.10/dist-packages/counterpartylib/lib
/blocks.py", line 206, in parse_block
new_txlist_hash, found_txlist_hash = check.consensus_hash(db, '
txlist_hash', previous_txlist_hash, txlist)
File "/usr/local/lib/python3.10/dist-packages/counterpartylib/lib
/check.py", line 274, in consensus_hash
raise ConsensusError(error_message)
counterpartylib.lib.check.ConsensusError: Incorrect txlist_hash has
h for block 823000. Calculated 3017c21e05aca875854fbe707aa9694771f
76bb768a064f290f017814fcec1bd but expected 53dd28b40d7ba79479445857
0fb880b108f9bc255f77721da128ac06f2e96e94
javi@3BA618D:~$

yo

Using normal start

With docker

yep this is almost certainly that non-determinism I mentioned

it's fixed on develop

as I said: if you hit this you can rollback to the last checkpoint. and rerun start

As I said it's fixed on develop but you may hit it again if you're using a tagged version. I believe a new release is forthcoming.

I’ve seen somewhere either multiple sources or destinations. Some old txns. But is not possible in the current “single message per txn”, I believe. Maybe possible with @jp_janssen compressed transactions?

xcp is not stored in utxos

How would what work? The VM? As the whitepaper describes, Counterparty is a state machine. A VM is also a state machine. The VM would be a state machine inside the state machine.

I have never tried but I expect that, yes, you can join utxos from multiple addresses. Counterparty interprets the first utxo as the sending address.

This does NOT mean you can send Counterparty tokens from multiple addresses in one transaction.

If both addresses are included as inputs, it *could* be possible right?

I would like to know a simple use case that uses said VM. And how that transaction (and the effect of this transaction in future blocks) would look like…

I am not sure what you mean by use-case. Counterparty's existing functionality is a (tiny) subset of what you could do, so technically Counterparty itself is a use-case. I'll let Adam speak to what the upgrade path might look like

yeah I don't know where to begin. Blockchains have had virtual machines for almost a decade now. They're used for everything. And they're strictly superior to hardcoded smart contracts, if implemented well.

It will be a new transaction type that provides input data into the state machine, which input data will include code to execute

our last discussion concerning the moral aspect of making asset descriptions optionally lockable would've been unnecessary

I’m really just asking basic questions on purpose. Because I know that most users of CP don’t get into the tech at all and support for the VM will be by faith / “blockchain buzzword” basically.

I don’t want to support it by faith. I want to understand how the protocol looks and works with such VM as part of it.

So what can be a good basic example of code I want to use as an input in this new transaction type…

The best way to understand how the VM will work is to look at how the EVM works in Ethereum. There will be a number of important differences ofc. but conceptually that's a place to start

The biggest difference being no native btc support unlike the EVM which has native eth support

Unless we get really creative with how utxo bound assets are handled

I know this will make some people angry but XCP would play the role of ETH. Sorry.

I have no idea why it would make anybody angry, but I'm continually surprised at the resistence people have to adding additional functionality... 🤷‍♀️

This is why stamps and btns came about. It really boils down to tx type.

I don't know what that means. Stamps AFAICT is primarily a riff of on inscriptions and btns is conceptually very similar to the original src20.

If Counterparty were programmable then there would be less reason for people to opine on how others use it.

That's the purpose of XCP. Being angry at it makes no sense, it's just the usual Bitcoin zealots

brought to you by the same people who thought that sidechains would get rid of the altcoin market...

You don’t see that those projects subverted the protocol? On purpose. For a reason…

i think that subversion is an absurd word to use in the context of permissionless systems

Or that think that lightning / L2s are enough to support the fees markets

any day now lightning will take over the world, I promise.

Sure, trying to get you to see my point is requiring interesting language.

Lightning is great. It's just that people never settle

When you are on the L2 you stay there

BTC is permission less. BTC doesnt need XCP.

I think that @mikeinspace and his team shrewdly caught on to a narrative of 'shitcoin-less' NFTs that Ordinals originated and found a variant with a different and complementary narrative

That did not need gas or xcp

... believe it or not I know that.

BTNS is the same

if you want a VM you need gas, if you need gas you need a gas token. XCP is the perfect gas token for the counterparty network; BTC is not. Sorry!

I don’t know if this is the best for CP. From multiple perspectives:

After many years, the top use case for ETH is issuing tokens/icos and dexes. And then came NFTs.

And there was Counterparty that could do both all along, with its asset issuances and dex functionalities.

The current protocol already has unused hardcoded functions. So users are showing the features they are interested in. All hard coded and simple to maintain.

Wanting to replicate Ethereum, which is resource intensive (anyone here has run a node?) and constantly hardforking, thus proving centralization, is not something I want.

I would rather CP continue in its path to “ossification” and decentralization. And being easy and cheap to run, both which also help in decentralization.

To me this means people will not like gas much.

NBD to me either way. Just my two sats.

agreed. this is why no one uses ethereum.

If you need to make backwards-incompatible changes for every feature anybody wants then you're definitely not encouraging decentralization.

Thats my point

This is FUD and has no connection to reality. You cannot go from "How does a VM work?" to "All VMs lead te centralization, hardforking, and high resource consumption." in a single breath.

I cant wait to run a node.

I do not understand what the fascination is with the smart contracts Adam wrote a decade ago. They're not perfect or exhaustive.

There are *many* things that Counterparty can't do, and there are many things that Counterparty can do today that it can do *much better*.

Faster, cheaper and easier

That's blasphemy, Saint PhantomPhreak

I think the main fns you need are: issue, send, trade. And the biggest feature is liquidity. I’m interested to learn more about the VM design.

About the running a node part, how many v10 are currently running ?

In my view Ethereum is centralized. Getting to consensus of upgrades would not be as “smooth” if it wasn’t.

consensus upgrades are independent of the smart contracts on the ethereum network.... *and that's exactly the point*

I think it's also because the vision of the community is different

"break things" is unacceptable on Bitcoin, not on Ethereum

But things are taking longer and longer to implement on Ethereum though

counterparty being forced into obsolescence because making it better stirs up fears of centralization (but apparently the software being too slow for anyone to independently validate does not??) is, like, not a good thing...

Has ANYONE here run an ethereum node? Or any VM blockchain?

yes?

VMs are not inherently slow or something...

also, you have a gas token to charge for compute 🤯

(Ethereum is absolutely too centralized IMO)

sure but centralization is not a monolithic concept

Ethereum has loads and loads of service providers, no one is gatekeeping which features it supports, etc.. Can Counterparty say the same?

I agree that upgrading a $500B network shouldn't be nearly as easy as it is with Ethereum ofc.

I’m one of the few that was screaming when CP added the reset, effectively breaking backward compatibility with the issuance message transaction.

I just dislike vague terminology like “smart contracts” lol. But we already broke a DUMB (transaction format) contract!

Which one?

every new feature breaks backwards compatibility so counterparty can be either effectively the same protocol it was a decade ago and just hope that people continue to use it out of loyalty or it can learn from the *decade* of development (done with infinite financial resources) since its inception

and it doesn't follow from the fact that previous protocol changes to Counterparty were botched that all future changes will be...

Ethereum, although going forward I will not be answering inquisitorial questions into which blockchain software I run...

Not sure what the overall plans for VM are or how XCP will operate as the gas. My opinion (shared by many) is that the main challenge with XCP (aside from narratives) is that it adds friction. Making the gas component seamless either at the protcol level or the tooling level will go a long way to removing that friction.

There are other things that can be done at the narrative level if XCP has "baggage" such as rebranding, though really the practical concern about friction is probably the more important consideration.

Is ok but it would be cool to share some of that experience. You still running it?

I am not but I ran it for years.

In the regular world friction implies opportunity, in Counterparty world it stirs up fears of everyone fleeing the platform 🤷‍♀️ In any case, of course we will all do our best to make it as seamless as possible.

Yes this I trust. But adding a general purpose VM is quite a leap in code complexity and maintainability… at least in comparison to the current limited hard coded approach.

And i assume node resources will need to be higher

(BTW @mikeinspace in case it's not totally obvious I do not understand let alone share the aversion others have to Stamps' use of Counterparty.)

Friction implies opportunity in Crypto as well -- early on. For instance, Ordinals were very hard in the beginning and arbitragers took advantage of that. As time goes on, the expectation is that the rough edges get smoothed off for the mass adoption plebs

sure absolutely... but I am surprised that no enterprising member of the technical community is raising their hand to remove the friction.

The technical community is very small. They are all in this room.

I do see steps to remove friction tho. RPW now has hardware wallet Ledger support. Its kind of insane how much value exists in hot wallets in this community

XCP.ninja with integrated wallet that even pays out royalties is a nice UX improvement

Trusted PSBT-support on OpenStamp

lol wasn’t my intention to stir the shit wrt XCP as gas by pointing out that the EVM lets you use ETH natively vs a Counterparty VM that wouldn’t have that same native functionality

I am also eager to see what Adam’s plan for a Counterparty VM actually looks like, doesn’t make much sense to criticize something that doesn’t even exist yet

The best example here is people choosing numeric assets over named, I built a proof of concept using numerics in 2019 to present at an NFT conference to demonstrate you could use counterparty with bitcoin only, also I believe using numerics for stamps was my idea (correct me if I’m wrong @mikeinspace)

I only bring this up as an example, not as a criticism

I would definitely give you that credit (and all the hate that comes along with that decision)

yep the great irony of all the criticism of Stamps is that they're using numerics _exactly_ as intended... but the intention was based on a botched narrative around XCP

If the VM means not requiring hard forks, then maybe it is a good path. But has any blockchain achieved this? From what I’ve seen is the opposite, and the ones without VM (like Bitcoin) are the ones with true backward compatibility

bitcoin has had a dozen or so brilliant people working on it for the past 10-15 years and still all you can do is send bitcoins back and forth in a variety of different ways. With Bitcoin stagnation is a feature not a bug because it's not a platform; it's money.

Counterparty pre-dated Ethereum. I remember someone sent us the white paper shortly before Counterparty was launched and Adam's response was basically "uh oh"

Do you think stamps would have the success it did if it used named assets?

wen lightning and wen chaumian ecash counterparty tokens

I mean clearly @mikeinspace is the right person to answer that

I do think that Counterparty is well positioned to leverage a lot of the new hype surrounding L2s and VMs on Bitcoin. Most of those projects are just vaporware, though in a way a vaporware project almost looks more valuable than an actual project lol... that's how it goes...

Who knows... can't re-run the experiment again for the first time. Feedback I've heard is that the "Bitcoin purity" narrative was an attractive aspect of the project along with the reduced friction of not requiring xcp.

I think narrative is very important in crypto and in many ways does trump the actual implementation. For instance, BRC20/SRC20 are absolutely horrible from an implementation peerspective. No one in their right mind would design something like that... yet here we are... BRC20 is by far the most used protocol on Bitcoin.

SRC20 is 90% of Stamps at this point

yeah I mean a lot of money has been shoved into Ordinals world surely because bitcoin zealots missed out on hundreds of billions of dollars of upside in non-money use-cases because they stuck their noses up at shitcoins

I can agree that criticism to something that doesn’t exist is not fair. But also, a lot of work and effort can be saved if the upgrade will not be accepted by all node runners.

I basically started the conversation asking for a simple use case. I haven’t received a specific answer. Only that it will work like an admittedly centralized protocol ETH’s EVM.

Then I say my concerns and they are labeled as FUD and thumbed down.

If I’m not convinced, expect me to continue challenging the idea

?

you absolutely got a 'specific use-case'

but that's totally beside the point: why should anyone's use-case need your approval specifically?

Again, for all this talk of decentralization I am really dumbfounded at people's desire to tell other people how to use Counterparty.

Maybe I missed the message, what was it?

_all of counterparty could be implemented as smart contracts in a VM_

So is basically changing the whole thing? Why not do something separate then?

?

I mean if people want Adam and I can go do something else I guess.

Was just curious of your take that’s all

Seriously, in terms of narratives, maybe this is the best approach lol. No baggage to handle

🤷‍♀️ people seem happy at our reinvolvement

Would hope that’s pretty clear at this point

Ser.

Juan speaks for himself

As we all do

Like I said, strawmanning something that doesn’t exist is not helpful, and it wasn’t my intention to stir the shit lol

I just never would have guessed that a decade later there would be a non-trivial number of people who are more partial to PhantomPhreak's Vision than PhantomPhreak himself

I think you have to look at it from a collector/artist perspective, they created/collected a thing within a certain subset of rules akin to the laws of physics for that digital object

Put into the vernacular of the industry: I know it's not a very Chad move to admit when you got things wrong but we got things wrong...

So changing those laws of physics becomes a risk

To them

Which could become an opportunity

From a collector mindset nothing is wrong with the platform remaining as is with only small incremental changes to keep it working, large changes are scary because they introduce existential risk

🤷‍♀️what if I told you Counterparty had exploited consensus bugs in the wild for the last few years.

I understand you're not advocating a position just explaining it but seriously this narrative of a conservatism is not based in reality.

I think your strawmanning a bit, no one wants a broken counterparty so obviously issues need to be fixed

but that's exactly the point: no one wanted to fix it.

Not true

...

Sir developers that can fix the issues do not grow on trees

I think you know that

I do know that, but that's the deeper issue

something about Counterparty doesn't attract those kinds of developers

Yes and I want more developers working on the protocol, everyone does

You’re strawmanning users by saying “you didn’t fix this so obviously you don’t care about it” when they had no idea anything was broken because it just worked

Narrative creates NgU; NgU attracts users; Users attracts devs… something like that.

Of course people want things fixed, no one would argue with that, but you need to know first what’s broken and second how to fix it

That wasn’t there

And when it didn’t work, “oh that’s a feature” 😁

As soon as you asked for funding for development did people step up and fund it?

this is my point @hodlencoinfield. There's a systemic cultural issue which I think the last decade has pretty definitively shown can be addressed by prioritizing the tech.

I am not talking about funding, I am talking about culture.

What is the systemic cultural problem? Not being a smart enough developer?

no...?

Like I said, how can you address a problem if you don’t know that there is a problem

How do you know if there’s a problem if you don’t have the expertise to identify it

Sir I do not know what to tell you, you know my position on this

I don’t!

I’m not understanding what you’re saying

Problems often don’t manifest themselves until they are tested by an adversarial environment. Dispensers being a good example. They worked fine until they didn’t

You say we have a culture problem because no one fixes the protocol problems they didn’t know existed

That’s nonsensical to me

Users put their trust in developers everyday by using software they don’t understand

What I am saying is that yes only a certain type of developer is suited to working on a system like Counterparty; and they respond to incentives. Those incentives are partially financial and they are partially technological. Counterparty today scratches neither itch. If Counterparty were upgraded to be the kind of platform in which XCP were an emergent requirement of the system the developers would come.

We just fundamentally disagree about the importance of tokenomics.

I’m not even talking about xcp

I am saying they're related.

inextricably.

You don't agree, which is fine!

Can I simplify your position to, developers should show up see that they can buy xcp at a low price then build a better platform to increase the price therefore increasing the value of their investment?

I do not know why it has to be simplified but sure?

I’m just trying to understand and not put words in your mouth

like, has everything been subsidized by VCs for so long that people just forgot that Bitcoin's survival (let alone thriving) is kind of miraculous

You’re strawmanning again, a lot of value has been built on top of counterparty without VCs, literally no one here is asking for them

Ok if that’s accurate then shouldn’t the low price of XCP over the years drawn in a plethora of devs based on that theory?

no because the narrative around XCP has been that its a nuisance which can and should be avoided at all costs

That’s an emergent narrative

yes, and I believe that if it can be changed then we can change the dev culture

there's an extreme hostility in the technical community to change. If you have the skills you'd be foolish not to apply them to a different crypto network

agreed, and to my extreme surprise there hasn't been corresponding activity with respect to the protocol, itself. The VC thing isn't a strawman; it's how _blockchains_ (not apps!) have gotten built since Ethereum. Whether or not you're asking for such a subsidy it's an implicit requirement if you want XCP to remain untethered from the system and have a good, stable, regularly improving platform.

Man we are repeating the same cycle.

Counterparty HAD NO DEVELOPMENT COMMUNITY, just until a couple of months ago!

It was all Jdog. Everyone trusted him.

When I started and saw the technical decisions that were made, and looked at the code, it was clear that the dev culture needed to change.

And at that critical point, my strategy (narrative) was about “we need to decentralize this”. Jdog cannot be the sole responsible for code changes.

@hodlencoinfield knows the story. And I have to apologize to him for having to bring this up. But I was very critical of him and that he was “approving” Jeremy’s changes without deep review and analysis. As he put it, they were “benign upgrades for the community”.

Since we have worked out differences and moved on and I truly respect that.

But now the founders come at a point when the groundwork of caring about the development state of the protocol was set.

But they don’t know this story.

And now coming and criticizing here about the development state is totally out of place.

So, to conclude, I would just say that we need to communicate respectfully. Try to understand our different perspectives. Let’s discuss the technology instead of charged characterizations.

I agree with that last paragraph wholeheartedly.

>And now coming and criticizing here about the development state is totally out of place.

you realize this only happened after you told me that maybe we should work on a different platform, right?

Only? But ok, let’s move on

* taps on last paragraph of Juan’s previous post *

https://youtu.be/5T_CqqjOPDc take a break

@marceh0le just updated the docs to show how to run kickstart with Docker: https://github.com/CounterpartyXCP/Documentation/blob/bc5416136e3b6797fc6eed60bbd5619895ce83b1/docs/advanced/how-to/docker-kickstart.md

As said several times, kickstart is going away with v11 (i.e. in a month or two) but for those who want to use kickstart with docker now have at it.

@teysol pointed out elsewhere you first have to update to latest pre-release, rc.1: https://github.com/CounterpartyXCP/counterparty-core/releases

I notice 'get_tx_info' could do with some love

I find it wont even display an enhanced send destination address.

It would be very very nice if get_tx_info were to work for all Counterparty message types

I am finding I have to extract the op_return from a tx hex, then rc4 decode the op return then further decode the hex encoded counterparty data to get useful information, that can be show to a user JPJA tx decode is useful to help do this client side but 'get_tx_info' doing it would be amazing

could you file an issue?

sounds like a great feature to add. thanks, bob.

I will open a github issue .. It would be ace to have that feature working well with all messages types

yep that'd be great. good idea!

issue 1573 created

Ahh .. I found the solution in the unpack() command, the destination address is shown in get_tx_info only when doing a legacy send, unpack() is needed for an enhanced send

Hey, if anyone is interested in continuing my work on xcp.dev new interface (https://960.xcp.dev/) please let me know.

I moved on to other things for now and so I haven't done much lately.
I can give a few pointers to the person that wants to continue on it.

Thanks