well I don't know what to say to that. you can call rejecting the addition of minor features even while pushing directly to master and having a broken test suite conservative, but I wouldn't.

no one is rejecting anything from what i see, just discussing pros and cons

and I certainly wouldn't call dispensers conservative.

dispensers were deployed in a bear market when a lot of people didnt care

on the contrary, it is apparently not only a terrible feature, but positively *immoral*: https://github.com/CounterpartyXCP/cips/discussions/135#discussioncomment-8431385

lol

Transfer ownership actually is not the solution is a patch

you cant expect a bitcoin protocol to survive 10 years and not have any fundamentalists

that fact that you can accomplish the same thing with burn addresses is just another reason to add the feature imo

since it doesnt really change anything anyway

You can't be in a protocol and technology like Bitcoin and Blockchain which innovation is a must and refuse it...

the only difference would be that you can still transfer ownership while the description is locked

that would be the new functionality

normally i'd agree but the bitcoin developers are — with a few exceptions — overmighty, pedantic prigs who love nothing better than saying no.

And issue more tokens and issue subassets and receive royalties and sell this right to royalties

so i think you could probly appease people by having an option to lock ownership transfer in the next consensus update

another thing i was surprised about lol

because subassets exists there is still a reason to transfer ownership of a locked asset with locked description

fundamentalism wrt counterparty's _features_ is not at all the same thing as conservatism wrt to its _development practices_. I am not trying to be a stick in the mud, but IMO there isn't some deep principle at stake here and I think it's important that that be made clear.

Per the comment which called adding a boolean to issuances immoral, Counterparty dev didn't 'move fast and break things', but it definitely moved slowly and broke things. the speed at which things are broken is not itself the measure of whether development is conservative or not.

we were stuck with what we had

understood, but then let's not make a virtue out of necessity.

but many more things would have been broken without the conservative mindset

this is the reason jdog forked after all

Counterparty isn't a general purpose smart contracts platform. It needs to listen to its users.

he wanted to change things

people didnt want change

asset holders are users

you can’t sacrifice existing users for new users

...by adding the option to lock descriptions of issuances.

thats the point keyuno is making in the repo albeit a bit dramatically

i think we should be able to lock descriptions fwiw

thats not what we’re talking about

you mentioned being conservative and said “well the maintainers just added shit haphazardly because they wanted to and THAT is not conservative” and my point is most users are stuck with maintainers because they dont have that skill set but they’re still allowed to think we should be conservative when making changes and adding features

they are not the same thing

but wrt lockign descriptions i think its a waste to put so much energy into arguing about since it is a rather benign feature

my issue is that the features discussion often obscures the deeper, underlying discussion. jeremy's fork was a really good example of that

in that case, the *important* question wasn't whether numeric issuances should have a tiny XCP fee, but really about XCP's role in the protocol. I can say that my personal rejection of the fork had nothing to do with the nominal issue, and even less to do with 'conservatism', but entirely to do with the fact that I think to be competitive in 2024 Counterparty needs a more sophisticated smart contract system with a correspondingly sophisticated gas system.

everyone has their own vision of the future

and we all want counterparty to succeed long-term

the timing is perfect for a resurregence, esp with runes launching in April

anyway, I am done lobbying for this feature. Suffice it to say, I think if there is massive resistance to as minor a change as this then that's bad news bears for Counterparty's future.

The use of XCP has always seemed a little arbitrary to me: why is a sub-asset 0.25 xcp? Where did that number come from? Why does a sweep use the amount of xcp it uses... do these things actually correspond with anything? A gas system does sound more "equitable"

funny i look at it and come to the opposite conclusion lol

as long as it also has diversity and inclusion then im in

i mean the only real counter-example to the statement 'doing something is better than nothing' is bitcoin, which absolutely lost out on a trillion dollars of economic value by being so 'conservative' (read: priggish)

Yeah the resistance is so beautiful imo lol

People used to don’t give a fuck. Every update used to be a protocol change. Nobody cared because xchain “worked”

oh sure, as a general barometer of people giving a fuck it's great!

low time preference 😆️️️️️️

but, like, how can you possibly imagine getting atomic swaps through if you can't get an optional lock on issuance descriptions lol.

we’ll get there

I believe if we remove XCP dependency for subassets… it will be HUGE

just gotta believe in blockchain jesus

roger ver?

i thought roger ver was the self-appointed blockchain jesus? this is just pepe in a wig with a crown of thorns

he’s the old jesus

_ah_ got it. makes sense!

more like judas now

this is extraordinary. who's the genius behind it?

I worked for him

lol

I quit after 3 months.

lol not sure who created this pack

roger?

Personally, I think we should not add new stuff to issuances until a deep evaluation of the current design is done.

And I believe the things that should be fixed before anything new is added are:

1. allowing original asset issuance data packing to be valid, as it should have always been.

2. no more resets. Full removal or redesign

Yes

he seems like a nice enough guy

Maybe, I don't really say if someone is nice guy or bad until I meet them in person.

Everyone has my trust until they betray me.

this is a perfectly fair position to take. features should not be added willy nilly with no regard to overall design, roadmap and tech debt

not all opposition to a new feature is "conservative". sometimes that's just a nice word used to justify resistance to fixing things or making them better

Is about context.

From my experience in the last ~2 years, there used to be no accountability / review to the changes in the protocol. I was told “every update changes protocol” as if this was the norm. It was fully centralized and “users” didn’t care.

After 2 updates, both which I had concerns with, we are here. Some good features were included, but some don’t. Like we are deeper into the issues with dispensers with the “close delay”. And the “backward compatible” issuance message id was fixed halfway.

The sad truth is we would be in a better position to fix stuff today if the v9.61 update was never done. Even more if v9.60.

So the “conservatism” emerging nowadays is a positive change in the development culture of Counterparty. A first step.

And thankfully, we are currently focusing on just improving the protocol for the next release. No new features. And I think we should continue this path.

Only after the protocol is the most efficient and integral with optimizations and fixes to the current feature set, I would consider adding new features.

this is a reasonable perspective

Yeah, as I said, it's obvious that the opposition to the description locking feature e.g. is a reaction based on history that I wasn't here for. Those updates you've mentioned had major problems and I'm shocked that they were pushed through.

But that doesn't justify a persistent misunderstanding of how things actually work—mixing up what kind of change is big, dangerous or ugly, and what kind of change is small, simple and useful. It also doesn't explain the confusion between protocol and non-protocol changes... for instance, literally _none_ of the work that has been done on Counterparty since I rejoined the project has affected the protocol in the slightest.

I agree with the arbitrary part of your comment. I always thought that 0.25 subasset was odd. Some type of subassets should be free under a named asset, or numbered subassets under a named asset. Something like that would solve several organizational issues with regards to how many projects use the protocol and incentivize adoption and proper protocol implementation. XCP fee should probably be more aligned with transaction type instead of asset type.

I have been following Juan for those two years, he speaks the truth.

Hi, all! Can someone familiar with the dispensers logic please weigh in here: https://github.com/CounterpartyXCP/counterparty-lib/issues/1408

@hodlencoinfield @uanbtc @jp_janssen just want to call your attn here 🙂

just added a comment, it might be related to dispensers not working on p2sh addresses, not totally sure, i can ask javier

yeah that'd be great @hodlencoinfield. thank you!

from Javier… “hey man, that fix was added by my brother, seems like something to prevent other addresses than p2pkh to trigger dispensers, most probably cp was crashing because of this”

Thanks. Would it be possible for him to post that on GH?

yeah i just asked, looks like he’s afk

Anyone have some testnet BTC? looks like faucets have dried up. If so please send here: tb1qy9s4afrglrg407ypn6jy53ulj3ha8saqw4m94f

yes... super hard to find testnet bitcoin...

i don't need much. really just dust

Don't have any ser sorry

np thx :-/

got some! please don't send more. if you can spare some tBTC send it back to faucets. thx!

I

I'm at 798845 synch with my fednode, based on this timeframe I think it would be better to have stood up a massive instance and gone thru this faster. This is what I would do with the ORD node each time the DB needed to be rebuilt. I also think having a known good boostrap would be helpful to allow devs to get up and running faster.

I 100% see the value of being able to prove from a zero top synched node and I'm happy to do this, but getting a dev node ideally would be faster than weeks

That's being worked on

100% I know that it is going to get faster

I think should be within a day

There's a kickstart function that reads block data, it's something you can do when the bitcoin node isn't running.

sorry reading my post seems off a little, not my intent

Ord is kind of wacky, they have so many indexes they are maintaining

yeah we're working hard on it @robotlovecoffee

and making good progress

cannot wait to have the ability to stand up stuff quickly and help others do the same, will work a video to walk people thru it

my latest full run with develop to block 700,000 took only 15 hours :)

I think counterblock is the only thing that is slow af for me

n.b. was on an M2

and with kickstart

sorry as I re-reading it my post is a dig and should not be, sorry, just had a long weekend with tons of little kids and burnt out a little and checked my node and was like fck...

Mine finally catched up 🎉 but none of the hashes are matching (haven't found out yet since when)

kickstart does the full parse as fast as possible accessing the bitcoind db directly (which you have to stop bitcoind temporarily for, yeah)

ach yeah that's another problem we're working on solving

dev is moving v fast right now, but we haven't cut a release yet because of problems like that

we want to test everything thoroughly, esp. because we're making major architectural improvements

more that is that case (not sure if older CP would work) standing up a stupid big/fast instance I could get stuff done in 8 hours then download the index.redb

happy to try test setup on AWS if helpful

so a bigger instance isn't necessarily going to help yet

right now Counterparty is still mostly single-threaded

we're starting to split work up across multiple processes for parallelization now

so that a bigger machine _will_ help

when performance is this bad, it's a major barrier to adoption

so it's a priority to fix

(it's also a barrier to testing and development)

dope, my goal is to get another ubuntu box for the shop and have a local node running

yes! more people running nodes 🙌

soon(tm) it'll be much cheaper, faster and easier

hope to have at least 2 running, local dev and a prod on the cloud

worth pointing out that this is one reason it's _super_ important for folks to run their own nodes (without bootstrap). helps us catch this kind of thing as it happens as opposed to having to do blockchain archaeology

of course, others independently validating the blockchain is contingent on it being reasonably fast, easy and cheap to do so.

Dear diary,

Soft-launching in a few chats (bitcorn, stamp devs, counterparty devs). It's yet another counterparty explorer...

https://www.xcp.io/

I've been a power-user of xchain and it's legendary, ofc. I also really like what xcp.dev is working on. And I am following along with those developments. The latest that I've seen looks really great.

I'm excited by what 2024 could bring for XCP and it motivated me to put this together, it's been about a month to here.

I'm going for MagicEden-look, with a focus on NFTs and trying to thoroughly cover all possibly collections I can find.

There's a "Discover ✨" button that is a blast to press and stumble upon stuff.

For example, SEIMEI:
https://www.xcp.io/collection/seimei-coins

Previously, I made xcpdex.com, digirare.com, bitcorns.com, but they're pretty old (2016-2018) and don't work, not that they're used much.

The mistake I made with those sites was re-implementing Counterparty which made it very difficult to stay up-to-date with new releases and changes to XCP.
https://github.com/droplister/xcp-core

This time around I think I might be slightly smarter. I'm just indexing messages, assets, and addresses.

I don't try to manage or compute Counterparty state in my app, except I get_asset_info when I detect new issuance messages.

For state, I query fednode endpoints in my app and append info like divisibility and supply, when they're not already there, and then I cache the results.

It's Laravel on the backend and Nuxt on the front. It's not state of the art, don't look at the commit history.

And I've scraped the crap out of every site for images. I found media for 81k assets.

When we get to APIs for explorer, I have some insights to share.

Latest telegram scam trick, be careful fam! ✌️

Shiney

this is incredible

this is amazing to finally have a good list of all the projects and "currency" tokens to surf through this way

https://www.youtube.com/watch?v=JxwvDZatBtc

bro, fighting the battle

https://open.gitbook.com/~space/q35Zi7Vn32SEeq7uKoeH

I have paid the gitbook subscription, if someone wants to join and start documenting counterparty properly, write me to add him.

I will put my notes there, on how to build transactions, and how the protocol works... it would be great if we could document the changes the protocol has had over the years.

dope

Bad link

Awesome interview @teysol !

Anyone have a testnet asset they can send me?

/ can anyone say whether they've been able to burn BTC on testnet recently

if so here's my address: mopY6BPwL9Nt75QugpTG5VtH43ZyKuaEYZ

okay, different question: I am using the 'unofficial' interface between hardware wallets and bitcoin core: https://github.com/bitcoin-core/HWI. I've got a watch-only wallet set up from which I can construct txs with bitcoin-cli, sign them with hwi.py and then broadcast them with bitcoin-cli. Clunky, but all good.

I'd like to pass unsigned txs constructed with counterparty-cli to hwi.py for signing, but it looks like the latter expects PSBT transaction format.

ATM I am looking to sign with a Trezor specifically. Does anyone know whether you can pass non-PSBT-formatted txs to Trezor?

I know that freewallet supports trezor so I guess there's a way. anyway, lmk! thanks!

It doesn’t answer the question exactly, but you can use Bitcoin-js to import raw hex as a transaction object, then loop over the inputs and outputs of thetransaction object and shove them into a PSBT object that can be easily signed

I also think Bitcoin core has a magic command to convert raw hex to psbt

https://developer.bitcoin.org/reference/rpc/converttopsbt.html

michael saylor needs to pay someone to redesign bitcoin-cli. it's awful.

but thanks for the tip, derp!

Let me know if it works with a tx generated with counterparty-cli

I haven’t tried it because our use case require web wallets so we just went the Bitcoinjs route

will do. unfortunately there are separate issues with counterparty-cli which I'm having loads of fun discovering

I'm really curious to know if works too

What issues ser?

having to pass --unconfirmed (which is positional...?) to spend utxos that have many confirmations, for one...

No luck:
bitcoin-cli -testnet converttopsbt 0100000001a3f434bf81af261dac925a6bc922
de19bff507d8efe1d1b5739adba30b3aa03f000000001976a9148adebeea13872ac54e653068c5a0e84a1a
11ded288acffffffff0250c30000000000001976a914a11b66a67b3ff69671c8f82254099faf374b800e88
ac53362e00000000001976a9148adebeea13872ac54e653068c5a0e84a1a11ded288ac00000000
error code: -22
error message:
Inputs must not have scriptSigs and scriptWitnesses

You may have to pass false true for arguments 2 and 3

oookay

It should be able to work with witness data

heyyyy it worked.

Nice!

Good to know this

we hit a snag

don't you ever sleep, javier lol

What snag?

signing ain't working

If you ever want to buy more than getting dust from faucets, I found this exchange a while ago where you can buy testnet bitcoin https://altquick.com/exchange/market/BitcoinTestnet

I tried it myself and it worked 😊

Since I tried it I ended up having a small bag so if you still need some lmk ✌️

Tf

yeah, testnet coins get value :/

that's why if you look in your ~/.bitcoin directory you'll see testnet3... they reset it from time to time in order to wipe out the price.

bro i was checking
https://github.com/CounterpartyXCP/pycoin_rs

https://github.com/blocklack-team/counterpartydb/blob/main/src/bitcoin_utils/mod.rs

why dont extract the logic to decode_tx from our repo?

is possible to load rust functions on python?

thats cool if possible

if you are working on your own implementation let me know, so i can integrate decode_tx functions from my repo into pycoin_rs

ouziel is here:?

he isn't. he doesn't like telegram lol

bro can i start working to migrate the decode functions to the pycoin_rs repo?

my implementation decodes 100k transactions in 8 seconds... if it can be called from python it will surely be an improvement in speed

Sorry 200k tx in 4.17 seconds

But I would say that 200k can be decoded in less time since the tests were done in an RPC call.

we've already switched to deserializing transactions in rust for counterparty-core

In the cases where the original code had an error or handles some txs oddly, what are you doing in those instances?

Are you computing the same state

we're only migrating low-level functions, and we're testing the new implementations carefully

(and discovering bugs in the Python :/)

we're absolutely going for bug-for-bug compatibility

we don't rewrite code in another language just for the sake of rewriting it. here's a recent flame graph of the kickstart process. if anyone can think of a good way to optimize it, please say so.

(as stated, base58_check_*(), script_to_asm() and arc4() are already implemented as small Rust modules)

also, we're currently working on running get_tx_info_new() in parallel using multiprocessing, which I'm hoping will lead to another ~40% speedup 🤞

unfortunately the way that dispensers were implemented makes it unnecessarily and unreasonably tricky to parallelize

@teysol the main benefit of putting dispensers on-chain is that the user doesn't have to keep his wallet open, right?

I mean I don't think the original design took into account the various trade-offs across designs...

You're basically saying not to overthink it lol

lol yup

right now, dispensers are on-chain but also have the trust model of a completely centralized service

you could make it trustless and off-chain I think?

just at the cost availability.

hm not quite

can you explain?

I think we’re back to no layer 1 rules enforcing deterministic behavior in counterparty.

IMO we should consider moving to support *both* centralized services (which would require hosts to keep their wallets open), *and* on-chain, atomic swaps that are trustless (using PSBTs)

then we won't have any compromises

The current transaction structure always requires 2 tx to ensure deterministic interactions between Bitcoin and counterparty assets

gotcha, makes sense. seems like a very good middleground

The decryption of arc4, I have always seen it as unnecessary to do it in the core, I think that logic could be transferred to the frontend.

I came across this Rust library this year, it may have useful ideas or code for kickstart. It’s really well organized code.

https://github.com/Congyuwang/Rusty-Bitcoin-Explorer

is there a specific reason to use arc4?

@droplister bro you were working on something in rust for CP right?

Not for CP, no lol. If you recode counterparty, I think it makes sense to launch a new thing you have more freedom vs figure out how to make it all work. I call that vaporware project Artifact. But if you are the founders of Counterparty it does make sense to make it all work haha.

Like, in my vaporware roadmap, I would purge bets, rps, dispensers, broadcasts.

nothing would be easier than starting again. the challenge is of course not to lol

For sure

I think you guys are uniquely positioned to make big changes and have everyone agree that that update is the true Counterparty.

That is good to hear. I am surprised that there are some people who are truer believers in Counterparty as it exists today than we are lol

But the reason not to start again isn't because it's our baby or whatever, but because there's $1B of assets and 2.5M txs on the network.

I am an advocate that a decentralized protocol and algorithm must be agnostic, i mea, it does not require a specific implementation language. a decentralized protocol must comply with a principle based on rules that can be applied as a form of consensus.

and a community whose commitment to the project is humbling and tbh pretty surprising.

That’s a nice idea in abstract

I have been putzing around with counterparty since 2015. A decade with an old friend.

just amazing

im collecting assets since 2016

filling my bags recently

just holding.

10-20 years

yeah, that's the thing. its age and its fairness lend it a legitimacy that you can't really buy with money.

the question which I think is open is: can we make the kinds of improvements necessary in order to rank with projects that _did_ raise 10s or 100s of millions of dollars and are now worth tens of billions.

the money actually isn't the biggest question there; we can stretch a dollar with the best of them.

rather: does the community (specifically the technical community) have the will to evolve with the times.

In these times it is important the speed and capacity that a network can handle for its purpose, CP will always be tied to Bitcoin speed. but if CP can be used to build things on top of its protocol yes, we need to improve many things about CP.

I always thought its reliance on Bitcoin would hurt Counterparty, but it's probably one of the biggest things to have kept it going all these years.

an example of this is that I recently have a client and I would really like to be able to use CP to work with this client to build his business on top of CP. but unfortunately, I can't recommend building on top of CP, I know that the @teysol and ouziel team are doing a good job to improve many things, and when we reach a good stack of documentation and technology that my clients can build on top of CP I will definitely recommend them to do so.

i think we need two releases to bring it back up to par

i.e. address consensus bugs, performance, deployment and documentation

we can start on the fun stuff after that but in two releases it'll look like a well-maintained and professional project

I previously had 2 clients for metaverse and gaming, and I really tried to do it in CP, but the previous dev core was always busy and things broke frequently.

I appreciate that the communication has improved as well.

trying our best. moving in a lot of different directions. we know we're not perfect so just bump us if we miss something.

and let us know what your clients need! the more product requirements we get the better.

here the metaverse and the game, in the end they were built in EVM.

I'll do it bro.

I am also interested in CP being used in many projects, that will also make my bags more valuable.

this will also allow in good conscience to aggressively pursue exchange support for XCP. Right now it's probably for the best that it's so illiquid

I don’t think any exchange ever used this setup, but making an address memo field required for deposits and using batched multisends for withdrawals is really a nice setup if they do it.

that's super interesting and a good idea

will definitely ask the community for help on how to move forward. we have _okay_ connections to exchanges, but not great.

Made the cut! lol

lol color me flattered

@B0BSmith do you have any more tips about running a node re: bitcoin.conf? You came in clutch with the maxmempool answer and my new node is currently 2% complete with initial sync.

Does more RAM, more CPU cores, or more connections, speed up the initial sync more?

Is there a public testnet cp block explorer?

@uanbtc i think that in his docs there is a param to increase cache that speeds it but i dont know exact param

i strongly recommend using counterparty-lib's README on`develop`

afaik it's the only documentation that's up-to-date.

Doing a fresh kickstart with develop and it's _so_ much faster.

4400 seconds in and I'm already at block 380k. I'm sure it'll slow down, but still....

in the next 4400 seconds did about 50k blocks. @XJA77 how does this compare to your 2 week catch up?

Wow ser

That's huge difference

Super cool

what is the recommended spec?

12hrs to block 700k! @teysol took 15hrs to get there (like a week ago??), and he's got an m2, i've just got a boring old i7. Ouziel warned us that dispensers start wreaking havoc with performance around 740k

Not sure I follow. I’m looking for the recommended settings. I can spec my machine up to 64 cores and up to 128 G of RAM on a SSD raid.

Around the time of the OXBT exchange dispensers. Related?

dispensers hurt performance badly in general and the and enabling dispensers for more than just the 1st output really, really hurts it

that's very bad of course, but unfortunately, in addtn it's possible for the 1st output to not be dispenser but succeeding ones to be...

so we need to do this v. expensive `is_dispensible()`check for every output of every tx since v9.59.6 I think...

This tripped us up quite a bit. There are transactions with both an issuance and dispense in them

yeah that's crazy

Im running 16gb 4 cores and it’s plenty with 1.6TB for fednode. Could get away with closer to 1TB especially without testnet. I’m usually scaling them up and down frequently.

We also multithreaded list_tx for the src indexing and get 0.5-2secs per block through the API. Excited to test kickstart. Is there an obvious branch for that update or in development branch?

check out develop!

does anyone know at what block height the multiple dispenses thing activated? the protocol_changes.json is not super clear...https://github.com/CounterpartyXCP/counterparty-lib/blob/master/counterpartylib/protocol_changes.json#L205

Multiple-dispenses, I believe was unintentional, but used as a “feature” so not sure there was a block height activation.

Cool thanks. the 1 day index time for stamps crushes testing time for code changes. Will definitely be hacking some of the test suite as well for stamps. Glad I chose to copy the Python code 🙂

@teysol block 819k is far later than when ouziel noticed huge slowdown...

I think I heard it was intentional to facilitate RP starter-packs and the like.

yeah it's all fine as an _idea_, but the implementation is rather problematic

but we can obviate all of the issues if we split dispensers into a wallet feature and proper atomic swaps and deprecate the existing design

then we'll have the best of both worlds

yes I want to take dispensers off chain :/

I mean yeah, dispensers as they exist today have the trust model of a centralized service... so there's no good reason for them to be on-chain

putting logic on-chain so users don't have to keep their wallets open is... a strange way to use a blockchain.

yep maximizing usability is obviously critically important, but there are better ways to do the thing

Bro thats insane

@reinamora_137 as someone who's dug through more recent versions of the code what's with the several protocol changes for v9.59.6 with different activation heights?

and the last protocol change for 9.59.6 (multiple_dispenses`) as the one for 9.60.2.

oh goddamnit telegram.. sorry for the bad formatting...

I didn’t spend much time with those aspects since all of the CP consensus stuff was yanked from our version because we decided it was just much easier to rely on CP for the CP specific data. As long as get_blocks is maintained we are all good.

About the dispensers, I encourage people to participate in the issue: https://github.com/CounterpartyXCP/counterparty-lib/issues/1331

IMO its most important aspect is the UX of “assets for sale at addresses”

Not sure if @mikeinspace here refers to several dispensers on one address.

Not to be confused with Periwig pointing out the problems with any output (not just the 1st) able to trigger a dispense, introduced with 9.61. I think we can remove the latter without much drama. Has it ever been used?

@jp_janssen interesting. Looking at the protocol_changes.json it's tied to v9.59.6, which doesn't make much sense with the block height activation, which is ~819k. Can you explain ?

Multiple dispensers on one address has been around as long as I can remember.

Dispense triggered by any output was introduced with 9.61.

When was the 9.59.6 release?

back in early 2022 looks like

Hmm, i have no idea what it refers to.

but the protocol_changes.json has it tied to multiple block heights...

9.59.6 protocol changes start with block height 745825 and end with 819300, which incidentally also is the block height at which v9.60.2 protocol changes were activated. I do not see any protocol changes associated with 9.61 in the protocol_changes.json.

Is this protocol change the one that does dispenses triggered by any output? https://github.com/CounterpartyXCP/counterparty-lib/blob/master/counterpartylib/protocol_changes.json#L444

Oh now i see.

819300 is Dec 1 2023.

The block seems correct but the version seems wrong.

hm okay! and this was 9.61?

Definitely the update late last year yes. That should be 9.61 if memory serves me.

( i am walking in paris now btw. Anyone here to meet up? Nft relic meetup tonight)

Everything went weird after 5.98

ok, yep verified that this is from 9.61: https://github.com/CounterpartyXCP/counterparty-lib/releases/tag/v9.61.0
"Added support for triggering dispenses on all tx outputs (view)"

Is anyone actually using this feature???

It _by design_ wreaks havoc on performance.

Okay slightly different question: what's the use-case for allowing a tx output other than the 1st one to trigger a dispense?

DNS resolution issues on counterparty.io rn?

hm yeah. @teysol fyi

yep! migrating to new website infra!

it just went back up for me

(minor style issues still need to be addressed)

api.counterparty.io back up*

counterparty.io still resolving

ok thanks. probably just a waiting game for dns to update

> api.counterparty.io
Server: 8.8.8.8
Address: 8.8.8.8#53

** server can't find api.counterparty.io: SERVFAIL

yep! sorry for the downtime

site's back up for me 🎉

still kinks to work out, however :)

Please admin

I’ve been studying btc script lately. I can’t articulate the thought fully right now and do not want to forget, but somehow CheckLockTimeVerify and CheckSequenceVerify may be able to help with dispensers?

not with dispensers but i think is part of the atomicswap flow

@herpenstein

Right, and we keep floating atomic swaps in lieu of dispensers too.

Atomic swaps with assets that can’t use layer 1 rules use time locks

Attaching assets to layer 1 consensus rules removes the need for such logic to ensure a deterministic swap

I would have thought that timelocks are layer 1.

Yea they are. And they are being used to allow data that isn’t on layer 1 to be verified before finishing the swap execution

Which is how cross chain atomic swaps work

You’re awesome. Thanks for the info and insight.

And how atomic swaps would currently work with counterparty assets

I need to research the counterparty tx construction code

I like to think about it like this: anyone can create an invalid counterparty tx that is a valid Bitcoin tx

That is true. I was thinking the same thing today.

with the current tx structure, you need one tx to create and mine a valid tx then another to finalize the swap

I guess I need to research atomic swaps irt BTC script.

In practice, with a time locked atomic swap, that would require each party to make 2 on chain txs

By attaching the data to layer1 consensus rules, the same thing can be accomplished in a single on chain tx

For some reason three tx’s sound right.

if all the data is on Bitcoin, 3 txs is possible

If any data is somewhere else (another blockchain) 4

worth noting that atomic swaps functionally aren't strictly better than dispensers (even if their trust model is actually correct, unlike dispensers), so in addtn to atomic swaps we'd have off-chain dispensers.

Is atomic swap a generic term an op code, marketing? Patented process?

none of the above 😄 it's descriptive.

Subjective

Relative

In one set of procedures a trust-less exchange of assets occurs

I’ve heard it used for multiple different organizational structures

Side question, do you all run fednode and bitcoin core on the same node/instance? Keep them separate or together? Pros vs cons?

I think you can just use simplenode at this point? much lighter weight

i personally run the whole thing on one machine without docker (but addrindexrs database is f'ing huge so that's on a USB)

I would rather stay away from docker too

Yeah I’m using fednode on two instances with everything and also a separate instance for a third btc node. Kind of like the segregation of them in docker.

What are your thoughts on the way DEX transactions execute?

so after weeks trying to get a node up the AWS crashed last night and when I started things up again and sycnhed was greated with this...

onnecting to database (SQLite 3.24.0-r1).
counterparty-1 | [2024-02-24 13:00:28][INFO] Connecting to backend.
counterparty-1 | [2024-02-24 13:00:28][INFO] AddrIndexRs connecting...
counterparty-1 | [2024-02-24 13:00:28][INFO] Connected to AddrIndexRs!
counterparty-1 | [2024-02-24 13:00:28][INFO] Starting API Server.
counterparty-1 | [2024-02-24 13:01:09][INFO] Client major version number mismatch (0 ≠ 9).
counterparty-1 | [2024-02-24 13:01:09][INFO] Rolling back transactions to block 278270.
counterparty-1 | [2024-02-24 13:01:09][INFO] Could not roll back from undolog. Performing full reparse instead...

I'm going to nuke the AWS and wait for a stable release that I can test.

sure wish this was c# using SQL server 🙂

whoa

you're still using master it looks like

this is xcpdev version

got it.

https://github.com/CNTRPRTY/xcpdev/tree/main/server/fednode

counterparty-lib develop removed undolog

as I thought it would be fastest to get up and running

That I cannot speak to, having never run xcpdev's version myself

not looking to solve but let me know there is a version I can stand up even if I have to nuke again

or once stable release I will stand that up

i've been using develop

are there install instructions for ubunto

i am running it on ubunut, you can just use the instructions in the README on develop

do you have bitcoind and addrindexrs caught up?

yes

then it's super simple

BUT this is in docker

ah

everything is in docker

?

so might start from scratch

I think so

got it. i haven't run that setup but it's totally doable

where is develop git

https://github.com/CounterpartyXCP/counterparty-lib/tree/develop

NB things get goofy around block 700k, but it's being worked on

there was a frankly somewhat ridiculous consensus bug which happily is not showstopping

being fixed on checkpoint branch

ok so to learn best path would be manual install from the git you linked

I think that simplenode is trivial to get up with Docker

But I installed directly on the host

you do need at the very least 1TB dirve

ya I think I want to be on host

I'd err on the side of more disk space. 2tb if you can

it's annoying as i'm sure you know, you gotta do catch-up serially: first bitcoind, the addrindexrs, then counterparty-server

ya this is just AWS so I can stack it up, I will be looking to get a local machine (probally rackmount) for local version and will have lots of space

ya I did this and the it crashed last night 🙂

ok going to nuke my aws and start again, this is all good stuff as I hope to make a video or document the process to help other devs that are not used to this stack

that'd be so awesome

we're killing addrindexrs in 11.0

after addrindexrs catches up, kill bitcoind and run counterparty-server kickstart

ok starting again today, lets see how this goes...

awesome yeah if you run into any issues post here.

ah just fyi https://github.com/CounterpartyXCP/counterparty-lib/issues/1446

only supporting 3.11 now (It was at like 3.5 or something a month ago!!!)

what version of ubuntu you running?

22.04 or 20.04

22.04

btc catching up as we speak...

https://x.com/mononautical/status/1761430076577517675?s=20

a new frontier for bitcoin

does not seem good, but I have a limited understanding

It’s not really good or bad imo, just the inevitability to trying to enforce Tx types through standardness

I thought it was allowing them to front run and mint all supply of a token?

Issuance > mint

This is just one application of private mempools

MEV is fairgame in blockchain.

yes I get that but normally saw this on ETH I thought

@robotlovecoffee how we doing on catch-up?

52k block height

for btc node

Wait 52k?

missing a 0 at the end?

523002

whew okay

🙂

cool! sounds like it'll btc will be caught up by EOD. Keep us posted!

folks, asking for a friend, has anyone run into the following error
× Building wheel for pysha3 (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [21 lines of output]
running bdist_wheel
running build
running build_py
creating build
creating build/lib.macosx-14.2-arm64-cpython-311
copying sha3.py -> build/lib.macosx-14.2-arm64-cpython-311
running build_ext
building '_pysha3' extension
creating build/temp.macosx-14.2-arm64-cpython-311
creating build/temp.macosx-14.2-arm64-cpython-311/Modules
creating build/temp.macosx-14.2-arm64-cpython-311/Modules/_sha3
clang -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -I/opt/homebrew/include -L/opt/homebrew/lib -I/opt/homebrew/include -L/opt/homebrew/lib -I/opt/homebrew/include -L/opt/homebrew/lib -I/opt/homebrew/include -DPY_WITH_KECCAK=1 -I/Users//Documents/Counterparty/counterparty-cli/.venv/include -I/Users//.pyenv/versions/3.11.7/include/python3.11 -c Modules/_sha3/sha3module.c -o build/temp.macosx-14.2-arm64-cpython-311/Modules/_sha3/sha3module.o
clang: warning: argument unused during compilation: '-L/opt/homebrew/lib' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L/opt/homebrew/lib' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L/opt/homebrew/lib' [-Wunused-command-line-argument]
In file included from Modules/_sha3/sha3module.c:20:
Modules/_sha3/backport.inc:78:10: fatal error: 'pystrhex.h' file not found
#include pystrhex.h
^~~~~~~~~~~~
1 error generated.
error: command '/usr/bin/clang' failed with exit code 1
[end of output]

nvm PEBCAK

710 getting closer

@droplister @uanbtc we're making our way through the checkpoints and are almost at the last one: 825k. Unfortunately, we have no reference database for blocks after that, as bootstrap db ends after that. could you upload and share a copy of your db?

(or anyone who's up to the currnet block height with master)

upload _somewhere_ not to telegram obv lol

.... anyone? lol

if you just need hashes you could just write a quick script to pull them all off the api of any of these public nodes

which nodes?

this is clearer... crazy!

I could host it

Can prepare it tomorrow

I have this up as a public cp api if you wanna compare hashes as an extra reference. Last I checked it was matching xcp.dev https://k6e0ufzq8h.execute-api.us-east-1.amazonaws.com/beta/counterpartyproxy

this is with the 9.61 fix

Nice visual

define nice lol

this is... not good 🤪

the super fun part is I think this fixes a consensus bug, right? so can't just revert it...

I'm not sure

5 block delay for dispensers was a rugpull fix not a consensus fix, if that’s what you’re referring to

ah okay

it makes rugpulling more expensive

this is just a workaround for putting a feature on-chain that never should have been :/

hahaha

Seller might honestly close their dispenser. Not necessarily nefarious

we know how you feel about it

not actually... frontrunning is still possible and is how they was performing this scams

frontrunning vs dispenser closing

checking when a payment has been done to dispenser address and doing a payment with bigger fee

frontrunning will always be possible with dispensers, they removed the frontrunning protection of btcpay

in stamps we have not seen any dispenser closing

was more frontrunning

bu yes i get your point

Like I said it could be completely innocent closing but buyer gets caught confirming after the close

but btcpay was not perfect either, in high fee environments getting your tx confirmed in 20 blocks may not be viable

psbt is the solution

tx is valid or not

yep kudos to @hodlencoinfield @herpenstein for figuring it out. gonna be a gamechanger!

I thought we have a 5 block delay on dispenser closing, so if you pay enough to get in within 5 blocks you are good, right?

unless someone pays enough before you

lol

How much “is enough” 😁

Oh I see

or after...

confirmed before

is what i mean

the point is it's not a bug in dispensers, it's just how they work.

yes exactly

So someone could just frontrun you with higher fees

so 5 block delay was to make it slightly more expensive, obvi its bandaid on an large open wound

And you get boned

you just have 5 blocks to duke it out, yeah?

or is it first come, first serve?

dispenser creator cant rug you be paying just a tx fee to close

got it, okay.

we'll fix it with atomic swaps, it's gonna be great

Front running is just part of it. Issuances have the same flaw right?

_and_ interoperate with ordinals.

yep

Awesome

can someone explain the dev discussion around to the 5 block delay? are people relying on it?

and every other utxo based bitcoin asset

borking the performance of the system is a major tradeoff for an incremental UX improvement.

getting everything interoperable via psbts is pretty incredible if you think about it

you get to have these offchain smart contracts via indexers (counterparty, ordinals, src20) and they can interact with each other via psbt

Can pbsts work with normal accounts, or does it have to work with ordinals?

Was there much discussion before it was implemented? Didn’t seem like it but I wasn’t following that closely.

i think thats accurate

Ie, require utxos instead of accounts like we have been doing up until now

it looks like it may be increasing parsing times by an order of magnitude...

not requiring

enabling

Ok, pbsts work with both?