Or would work once developed

i imagine a sort of multisend tx where you can send assets to multiple outputs created with that tx, then you can spend them into new outputs or into an address

you move assets in and out of UTXOs

Per Derp's CIP:
>Since Counterparty assets used in this way aren't permanently tied a sat, but optionally bound and unbound, when it comes time to move an asset out of a UTXO and back into a users wallet, the updated send function will be used. It will take the asset containing UTXO and user payments as input. Outputs will include the function to move the asset from the UTXO to the users wallet and the users change output.

Ok, I see

is like when creating the send there is a bind to an utxo

it's a major architectural change... like dispensers.

except awesome.

but back to the immediate issue at hand: is the dev/business/dapp/whatever community open to possibly reverting close delays?

i think so

I don’t think you’ll face any resistance. I bet most people don’t even realize it exists

I would revert a couple of things 🤓

the patch dont solve the issue and creates other issues so yes..

def makes sense to include any other pressing issues

it's not user facing and doesn't solve the problem, so I think it's quite compelling.

BTW we got to checkpoint @ block 825k

very, very good news.

almost there!

yes! I am honestly astounded, 6k blocks to go but if nothing changes no one will have lost money because of consensus breaks

and will not need to rewrite history.

i had faith

I honestly didn't

but still super happy

don't want to jump the gun, ofc...

whats 7000 blocks between friends

if it were between friends there'd be no need for a blockchain lol

If anyone's interested.... https://github.com/CounterpartyXCP/counterparty-lib/pull/1444/files#diff-47adff1c5b07e2a5af9594b85b9b3ec6811034b849d26499d3f57efcfe2263c7R323

BAD_ADDRESSES is a great variable name

this is very weird bug...

the culprit: https://github.com/CounterpartyXCP/counterparty-lib/blob/master/counterpartylib/lib/blocks.py#L800

script_pubkey[2:22] right?

yup

instead of throwing an error for an unsupported address type (p2wsh) the scriptpubkey was just truncated so it was a supported address type (p2wpkh)

what's neat is that when we release the fix the effect will be the opposite of what you'd expect from a consensus break: people will gain access to funds that had been effectively lost.

Yes lol

If all the addresses are invalid then is good

If some of the result address are valid and someone did some transaction with it then is problematic

i think mathematically it'd be impossible for any of these addresses to be valid.

sorry, they're *valid*, but unspendable.

can Mr Unspendable himself, @teysol, confirm pls.

sheesh i didn't even think about this; I assumed the way the seller rugged the buyer was by filling the order with a higher fee, but of course you're right, you can rug the buyer just by closing the dispenser. good grief.

that's correct

despite the dev team working on pbst... is it possible this protocol issue with 'minimum order amount' for BTCpay could be looked at? Alot of the users over many years have wanted to use this functionality (understanding the Auto BTC-pay and leaving FW open to do so).... but when they want to test it with low btc amounts, the protocol does not match orders

https://github.com/CounterpartyXCP/counterparty-lib/issues/1278

I can't say what order things will be done in. Quite limited resources and there are still lots of problems, but if you ping Adam on GitHub he can assign a priority to it.

I don't know what the upside of keeping BTCPay is if we have atomic swaps. Would be curious to hear others' thoughts.

I don't like being dramatic but you've got to understand that the code is basically in a pre-production ready state and hosts $1B of assets

I think users will still want a way to trade assets that aren’t bound to utxos.

its moreso an issue that has spanned multiple years without a fix... and in the meantime before atomic swap and psbt goes live users would love to use it and "have it work"... especially when its a trustless way to transact btc (and a very historical one as well that predates dispensers)

this is independent of BTCPay

dex will still exist

but overall was just looking to specifically have adam throw a priority status on it

dont want it to be lost and forgotten for another year....

In order to reach MVP we've got to fix: consensus bugs (which exist!), performance, and deployment. Issues with the latter two are why the first went undetected for literally years...

don't forget the potholes us users have been driving around for many years ❤️

love yall, just saw it being discussed and thought i would bring it up

I hear you, but the potholes need to take a backseat to making sure that the bridge doesn't collapse in on itself while people are driving. User-facing problems are bad of course, but if the consensus system can't maintain consensus then everything else is moot.

understood, just dont forget about the potholes on the side roads when you build your fancy new highways ❤️

🤷‍♀️can't please everyone

we haven't come across any unfixable problems (except features of dispensers masquerading as bugs). The speed at which they're fixed though is a function of time and money.

@herpenstein this is an overly-subtle point. The question isn't whether we have a way to trade Counterparty assets for each other without binding them to UTXOs; that's what the dex is for and it's not going anywhere. The question rather is whether we should maintain a way to trade Counterparty assets for BTC without attaching them to UTXOs given the problems with BTCPay.

And I can imagine having both options causing serious UX headaches.

the dex is suitable for asset to asset trading and has worked wonderfully for years, psbts are an asset to Bitcoin solution and are superior to both btcpay and dispensers

They solve the shortcomings of both

So would replace both then?

IMO yes

itshappening.gif

both features have been cause for various headaches

Yes because they were trying to solve the difficult problem of trading btc for assets

but you guys figured it out. Derp Herpenstein and Hodlen Coinfeld

Utxo binding plus psbts is the elegant solution

Well, ordinals figured it out

To be fair

i just like saying silly names earnestly

Its a bitcoin solution which means all the second layers can utilize it

I’m looking forward to the merging of the marketplaces in the ecosystem

samesies

It’s such a stark contrast to eth too, I love it

increasing liquidity helps _everyone_

really looking fwd to it. New dev, who will be working on it in due time, made his first PRs this weekend btw

AFAICT once you enable UTXO binding atomic swaps are strictly better than BTCPay. If you couple that with a standardized off-chain way of doing dispensers I think you've got a pretty good setup.

It’s not trustless tho. You need to have your txn confirm within 20 blocks or you can get rugged in a very similar fashion to a dispenser (except maybe safer because you do have 20 blocks). Safer… but not trustless.

No one is going to miss BTCPay because literally no one uses it because of how bad the UX is

Whatchu mean if order doesn't match it can simply be cancelled like dex can

Though this is true... Only one wallet supports it and has a big bug in it

Bitcoin is unique on the dex. At some point the bitcoin txn is broadcast. You have 20 blocks for it to confirm to get the asset. If it takes 21 blocks you’ve sent the bitcoin but won’t get the asset

Which just leaves it as an open order on the DEX UI in FW... Which means cancelling the order would return the BTC .. though haven't tested that specifically.. was just my understanding of how that feature worked

Bitcoin isn’t escrowed by the protocol. Bitcoin txn gets broadcast. Now you could try double-spending it back, but you can’t “cancel” it because it was broadcast. You sent bitcoin to another address at the base layer. The base layer has no awareness of counterparty

Gotchya didn't know that

this makes sense. i know it's crazy to hear in 2024 but in 2013 people didn't worry about full blocks

Mike, I assume Stamps relies quite heavily on dispensers, is that right?

would moving them off-chain be very disruptive if you had atomic swaps in addtn?

as an end-user I believe the only thing you really lose by taking dispensers off chain is the abilty to have the dispenser be both non-custodial and not require you to keep your wallet open.

(imo this is a bad reason to put logic on-chain. doesn't solve a trust issue, but just sort of outsources a business to the blockchain)

Yes, dispensers are the number 1 trading mechanism for Stamps - though tbf, src20 now makes up about 90% of stamps traffic and those don't use dispensers at all

how do you trade them?

at the moment therer are 2 different approach for it, stamped ninja relies on dispensers to trade stamps, also they use it as a way to send stamps to minters of src20, the other approach is openstamp that uses a custodial mechanism

Removing dispensers? That would be very disruptive to the broader CP community.

You're gonna laugh but its in the same insane way that BRC-20 are traded. You mint a "transfer" which is essentially its own stamp

having atomic swaps to replace them i think is a fair trade, also dispensers as i understand could be implemented offchain by anyone, just custodying assets, checking for incoming payment and sending asset right?

Trusted PSBT through marketplaces

🤷‍♀️this industry didn't develop as I thought it would at all

i'm not advocating it (though I think it's the right thing to do). atm i am trying to understand the community's needs. again, you wouldn't replace dispensers with nothing, but an off-chain solution. the only thing you'd lose AFAIK is non-custodial dispensers that don't require users to keep their wallet open. OTOH you get PSBTs

dispensers already were an offchain business at one point. OGs will recall Vennd[.]io

Then swapbots after that

would the new atomic swap method work with "supply"... or would the tokens need to be single supply?

I think there's some inside baseball I'm missing. @hodlencoinfield ?

idk what 'supply' is as a term of art.

Most people cannot maintain the server infrastructure to run their own offchain solution like vennd or swapbots

Right, I get that. I think its more a cultural thing at this point. Its very ingrained into the culture.

yep, that's exactly the tradeoff

I think if anything you need to ween people off of them by showing a better solution

I am going to speak out of turn and get berated privately I am sure but if I am not mistaken PSBTs and dispensers may be in conflict with each other, architecturally.

With a dispenser you can set one up with 100 or even 1000 supply and just let it run. With an atomic swap would you need to set-up 100 of them?

Many artists use dispensers as their sales channel because for a one time cost of a Tx fee I can sell 100 editions

This is where dispensers still have an advantage

right

That's very much the culture. Selling editions with a single txn

If they’re artist deployed then there’s no trust issue

could you do a decentralized minting thing as an ersatz for that

That’s not a bad idea

It is different tho and only works for new assets

I don't think there's going to be a perfect replacement

dispensers are unique precisely because of the tradeoffs they make

if you replace them with a solution that doesn't make those same tradeoffs you won't get the same perceived benefits.

There may be something clever you can do to keep it non-custodial, off-chain and solve the availability problem

You might be able to create a central order book but have users self-custody keys. Sellers sign txs, and a TTP broadcasts them when there's a matching buy.

idk just thinking outloud. might not make any sense.

Yea, I think there are def clever things with utxo binding we haven’t considered, functions in addition to “send to address”

the high-level requirements are: off-chain, non-custodial, and available.

we need Hodlen Coinfeld and Derp Herpenstein to have another revelation.

Yup that's basically what the Stamp marketplaces are doing "Trusted PSBT".

IMO this is a very reasonable middleground.

no one wants to custody keys. custodying signed txs OTOH...

TBH if there's no/minimal financial regulation around this it would be a _phenomenal_ business.

@mikeinspace who's the tx custodian in Stamps land?

The 2 marketplaces doing this are:

openstamp.io

stampscan.xyz

and those companies specificaly provide the service of custodying signed PSBTs and creating an order book?

Yes, and they take fee in the process. I think its free to list (and cancel) but if it sells, the signed txn gives them a cut

yeah, that's a phenomenal business model.

good for them.

Okay, I think I've done enough irresponsible brainstorming for one night lol. But it sounds like there are good options and middlegrounds.

actually it wouldn't be the signed txn giving them a cut it would be the buyer.

magiceden was sending all their fees direct to their coinbase wallet so they didnt even have to pay to consolidate 😆

yeah that was brilliant. They stuck coinbase with the consolidation cost.

so good

Apparently, coinbase routinely loses a shit ton of money sometimes >100% value in the process

yeah i saw something like 35 BTC extra over spend in fees

for just the magiceden acct

I should do this with my dispensers... I just did a consolidation and it cost me about $30 due to all the inputs

hahaha

1.8 million USD isn't worth the effort to even fix the bug lol

they’re printing money over there, thats barely a rounding error

a concern I have with an off-chain replacement involving a third party is that the latter of course would need to be paid for their services, whereas dispensers, as Counterparty users know them, are free. IMO that was a mistake: dispensers have a serious externalized cost (as is evidenced by how long block parsing takes) and should have had some sort of XCP fee associated with them.

In any event, is paying for a dispensing service something the community could adjust to?

A new gas mechanism need to make infrastructure dev work and business sustainable on protocol level ...all event as long as cost cp resources need to pay gas

Gas collected partially can be used to support dev ...fully paid job makes work more fast and motivated

you can't do that without centralizing the project in a way that I at least would not be in support of.

With the current tx structure, a user would have to trust their counterparty to perform any trade in 1 tx.

As things are now, a PSBT of an asset send in exchange for btc has the same downside as buying from a dispenser. If artists/buyers accept those risks, this structure can do something somewhat similar.

The artist would need x utxos and to sign x psbts

And if the artist doesn’t otherwise move the assets, anyone who executed a utxo would get the asset

Definitely more cumbersome, unless the ui allowed for bulk signing with a single click

And the expense of splitting utxos

Regarding the gas fee, definitely appreciate the need for it. I also can't proclaim what would be the best "engineering" solution, but an alternative proposal has been discussed a bit that might satisfy the requirements (addressing externalized costs) while keeping user friction low.

Essentially, user pays exclusively in Bitcoin and some of that Bitcoin is used to purchase xcp from the market and burn it (ideally all within a single txn). In this way, the gas situation is addressed while the user doesn't need to go through the friction of aquiring xcp.

Candidly, such an approach does "help" stamps as its more aligned with the project's "ethos" but I think it also helps Counterparty by ensuring a low-friction environment (user growth) as well as create a constant demand for xcp.

if its in xcp and is able to deploy multiple dispensers on multiple addresses (even if more in xcp) it might be viable... but with recent prices i might do an educated guess of 0.05 xcp as a number to start with... im not sure how the community would take that tho.... being so used to dispensers and dex using just a btc tx fee

something 'similar' in theory was discussed in the github somewhat recently here: https://github.com/CounterpartyXCP/cips/discussions/92#discussioncomment-8561841

It's 2024: if we don't have dynamic fees that scale with demand then we're hosed. I think as a rule no more hard-coded fees going fwd.

yep, Adam and I actually have built exactly this kind of tx chaining before. That was for a different kind of blockchain but pretty sure we can do it again.

@herpenstein good thoughts! thank you.

https://github.com/CounterpartyXCP/cips/discussions/120

yeah solution #2 there is to just reimplement BTCpay :)

but it's generally correct

With psbt do the seller and buyer need to be online at the same time?

nope

and with the wallet solution, just the seller does (and if the seller goes offline, then it'll work again as soon as they come back)

dbcache= setting in bitcoin.conf can help during initial sync

Add as much dbcache as your setup/ram allows whilst doing the initial sync n then drop it back to normal once your at the chain tip

832062 getting closer for those following along...

the PR to pass checkpoint @ block 825k was merged: https://github.com/CounterpartyXCP/counterparty-lib/pull/1444

This seems kind of slow for initial block download on AWS.About the same that I was getting with Starlink, while I was definitely being metered.

ya perhaps it is the instance as it is not crazy big

it is a t2.large

but based on monitoring does not look over utilized

anyway, once bitcoind is caught up should be unaffected by network stuff.

it is up todate now, so on to next step

@teysol just said this: "fyi I just did a kickstart on a GCP 4-core machine on mainnet and it took <24 hours to get to block 800k". @XJA77 what were the specs of the machine that catch-up took two weeks on?

Ryzen7 16gb

2tb

looking like a > 10x speedup on mainnet 😊

For anyone interested to see the externalized cost of dispensers, here's profiling done after extensive optimization.

it's even worse than than itlooks, because the whole reason we can't just run list_tx() in parallel is that the dispenser logic breaks an important abstraction boundary by writing to the DB when parsing vanilla bitcoin outputs

Right :/. Is there a way to quantify the corresponding performance hit to that limitation?

or is it basically just taking list_tx() down to zero

the latter

hopefully we'll still be able to parallelize the rest of list_tx(), but it's much harder

list_tx() and dispense() together account for 60% of block parsing time lol

Some people still trust.

24 hours is on par with ord

ah great!

even longer for ord if you enable sat-index

that's an excellent metric

does ord parsing also have to be done serially wrt bitcoind catch-up?

yes, you wait til bitcoind is caught up before running ord

wow that's great for us

nice find @hodlencoinfield

would know better running both on the same machine

better comparison anyway

@teysol when we kill addrindexrs we'll be bringing the necessary indexing in-house, yeah?

👋

how do you imagine that change will affect performance?

so we're still digging to find all of the ways we *actually* use addrindexrs and what we really need it for

it might be the case that we don't need to index all transactions for all addresses for instance

it might be that we can trust a bunch of servers because we can locally verify the results perfectly

right.

but whatever indices we can't get rid of, yeah I think we'd build and store in our own local copy of RocksDB

aren't there privacy implications to this?

(I agree the security concerns are not real)

I don't think so, but it depends on how we use them

for instance, if we only need to ask for the pubkeyhash -> pubkey mapping before we construct a transaction, then there's no privacy leak because you're about to broadcast that same data to the blockchain :)

in any case we need to do more digging first

obviously eliminating addrindexrs from the stack would be great since then counterparty-lib would only need bitcoind

yup exactly

I feel pretty confident we can do it *somehow*

and it'll be a major win for usability

maybe just incorporate some of its functionality directly into counterparty-lib

targeting v11.0?

yup, not definite though

the biggest benefit is for block explorers and wallets

being able to query txs by address is a necessity for both of those

I think an issue is that if I'm not mistaken with 9.61addrindexrs became a consensus-critical dependency.

i'm getting the following error as I used 8333 and not 8332 I think

not sure how to reset and if I need to rebuild

export ADDRINDEXRS_INDEXER_RPC_ADDR=0.0.0.0:8432
export ADDRINDEXRS_DAEMON_RPC_ADDR=localhost:8332

not sure when it started tbh, im not sure how dispensers would work without utilizing that to some degree

I think I need these to be 8332, sorry just the 2nd one

i was under the impression it was a necessity prior to that which is why we always used the btcdrak patched core prior

I believe drak's patch was for wallet functionality, not consenus-y stuff

but seems it was just for counterblock and counterwallet

@robotlovecoffee what is your error?

WARN - failed to connect daemon at 127.0.0.1:8332: Connection refused (os error 111)

running cargo run --release -- -vvv

do you have the right auth credentials?

wallet functionality IS still important but yeah that was a misunderstanding i personnally had regarding why it was necessary

no argument here.

so the default bitcoind mainnet port is 8332; ADDRINDEXRS_DAEMON_RPC_ADDR tells addrindexrs what port to use to talk to bitcoind

my .config is

rpcallowip=127.0.0.1
rpcuser=rpc
rpcpassword=rpc
server=1
txindex=1
rpcport=8333
addresstype=legacy
prune=0
mempoolfullrbf=1
listen=1
dbcache=4000

ADDRINDEXRS_INDEXER_RPC_ADDR specifies the IP and port that addrindexrs uses to host *its* RPC server

we actually just deleted all of these config options from our recommended setup

now we rely on the defaults

:)

so he should pull develop for both addrindexrs and counterparty-lib and counterparty-cli, yeh?

no need

ah awesome!

he just needs to remove all specifications of the ports for all services (including the ENV variables in his .bashrc or whatever, and restart the shell)

if you don't specify any ports on the CLI, in ENV variables, or in the config files, then on mainnet:

bitcoind is on 8332
addrindexers is on 8432
counterparty is on 4000

and they should all connect just fine (at least if you're not using Docker)

sorry for the lone windows dev here... I chaneg btc .config to remove most but not all right? I still need txindex

for btc config just remove the rpcport I think. everything else is fine

restart shell is reboot instance?

nah

just the BTC stop start

just open a new terminal, you didn't globally set those env vars

to pull new vars

so at the moment I ssh into my aws start a screen for btc node and run it, then I was trying to create another screen to get the addr working

and for counterparty/server.conf

I assume I stop btc node to pull new .config

yep i think that's right

and for addrindexrs

afk

TXID_LIMIT 😭

does excuting this overwrite existing vars

yes

ok

consensus-critical environment variable...

INFO - NetworkInfo { version: 260000, subversion: "/Satoshi:26.0.0/" }
INFO - BlockchainInfo { chain: "main", blocks: 832136, headers: 832136, bestblockhash: "000000000000000000015106f35ac24de60a371a2382cbf5b192a852f1837993", pruned: false, initialblockdownload: false }
DEBUG - opening DB at "./db/mainnet"

all good!

got something diff so think that might have worked

yep, give it a sec

addrindexrs logging is inconsistent and bad so don't read too much into it

this is the message that lets you know it's working. (NB: it'll write to directory mainnet if you're on testnet, so if you want to run a testnet instance probably should specify a new addrindexrs db-dir)

@robotlovecoffee just fyi addrindexrs does some compaction thing that gets its db down to ~132GB, but before that it's > 300GB. I think you should provision for 500GB

i did a 1.5gb disk

TB?

1.5tb should be plenty.

fck yes, T

If you know what commands would produce what you want I can expertly paste them.

lol all good! we got what we need. thank you, though!

@robotlovecoffee it's hard to know when addrindexrs is done but I think you should see a message that looks _something_ like this:
DEBUG - applying 0 new headers from height 832149
INFO - Indexer RPC server running on 127.0.0.1:8432 (protocol 1.4)
would be great if someone else could confirm.

how long should I want to check?

tomorrow?

Ord starts indexing in parallel with Bitcoin, not after

that must be new

i have to run ord index update any time i want to catch up to the current block

About the discussion of dispensers, I think it will be hard to replace with a better UX. So I think it should be about optimizing what currently exists:

1. Only check the first output (multi outputs was added in the last release so we can include it as part of “reverting recent bad updates”)

2. No more always open for free. Adding an XCP deposit for keeping the dispenser open. This XCP is deducted per block by X amount until depleted. Or if the dispenser is consumed, the XCP left is returned.

Maybe, is my experience with the latest version I’m running

So tentatively it seems that there may be some conflict between atomic swaps and dispensers. I can't opine on the details, will leave that to @teysol.

RE: the optimizations you mentioned:
1. doesn't work unfortunately, because of the design of dispensers. You can't break after the first is_dispensible() returns True, since dispensing addresses can call other dispensers.
2. totally in favor of adding fees along the lines you described: I'd make it similar to a margin position, where the fee is in proportion to the value of the dispenser (way to determine that is itself TBD) and how long it's open. I think the performance impact of a dispenser also grows in the number of dispensers that address has opened, so I'd add a fee there, too. And yeah, I'd make it extremely expensive to close the dispenser. In any event, the fee system would mean that 'set-it-and-forget-it' dispensers are no longer a thing.

(1) and (2) would massively degrade the UX of course, and would therefore make the argument for keeping the logic on-chain less compelling. But even if the UX were the same I am personally strongly opposed to putting applications on-chain if the only upside is UX (as it is with dispensers). I try not to be opinionated on how the blockchain is used, but dispensers make Counterparty worse for everybody else both directly (by wrecking the performance) and indirectly (by making the codebase much less maintainable).

The real way to get the desired UX is for somebody to run a business doing off-chain what dispensers do on-chain. In the absence of that, we can do our best to approximate the UX of dispensers in a wallet. Will it be perfect? No. Is the tradeoff worth it? IMO absolutely.

Unfortunately the users, the sellers and buyers, don’t see any of the protocol performance issues. And buyers won’t see any UX difference, so I wouldn’t describe it as a massive degradation. And really, the buyers are the most important users to please in UX.

For them, dispensers are great. And it is shown by their popularity.

The only “negative” is the front running, but that is just part of it all as it also affects the most fundamental protocol action of issuing assets.

And I’m in favor of adding new ways to sell assets offchain, maybe with better “deals” (clearly for sellers as they won’t have to burn XCP to keep them open) than dispensers. But removing dispenser’s buyer UX as it exist today is not practically feasable imo.

if there is a choice between atomic swaps and dispensers, which do we choose?

For the perspective of CP, dispensers are like an atomic swap

I am not sure I follow. So by that logic, it's okay to get rid of dispensers if we have atomic swaps, yes?

The buyers will see one important UX difference: fewer dispensers because punitive fees (and they don't make sense unless they're punitive) will price sellers out.

does anyone know how this is possible?

Well yea definitely less dispensers if they stop being free for sellers.

The “atomic swap” happens when the recipient address receives enough BTC for the dispense. After confirmation, the BTC was exchanged for the asset in a single transaction

Haven’t studied those implementation details

I mean atomic swaps as detailed in Derp's CIP: https://github.com/CounterpartyXCP/cips/discussions/134

its not a binary

Yeah that is why I said “like atomic swap” here

you have to ween users off of dispensers and onto the better solution

Atomic swaps probably aren't going to be able to replicate the slick UX of dispensers. But if we can get wallets to implement the dispenser functionality without relying on the protocol message, we can ween users off

and then atomic swaps will complement that

one thing to consider is that any offchain solution to dispensers incurs a lot of fees to the operator

would be a tough sell

why would the fees be higher?

because the fees have been eaten by the nework as a whole up to now

Costs he means I think

because the operator doesnt send individual assets out when they receive payments

with dispensers

True

so you could sell 100 editions for one tx fee

or 100 editions for 100 tx fees

hm yeah that can be resolved with atomic swaps

it's going to be a complicated solution, with lots of user testing

I think it will be about options. Dispensers will have a cost for sellers now, so that gives the alternatives a way to compete

yes, i think its def possible to be creative with the “binding” tx so that you can create 100 outputs and send 1 asset to each of those outputs in a single tx

so yes it will be a higher fee than a dispenser creation but its still done in one tx

and the selling point is that there’s zero risk of having to send funds back to people that sent btc to a high demand dispenser and didnt get anything

But front running won’t be solved right?

it will be solved in the fact that the loser doesnt lose money

their tx fails

front running would be solved by atomic swaps

Ok yeah that makes sense

front running still would exist because thats how bitcoin works, but yeah either your tx is confirmed and you get the asset or its not confirmed and you dont

but no funds lost

Well… I’m not fully understanding it yet. What if I do another psbt with a higher fee? I might be missing something…

it would be an auction in that case

and no one would lose money

Ok

private mempools help mitigate that

which is what the brc-20 community is finding out

How would having many dispensers in a single address work?

In the atomic swap alternative I mean

actually they probly make it worse lol

to be clear: the UTXO tracking necessary for Derp's CIP will have a substantial externalized cost, too, so an XCP fee for binding counterparty assets to UTXOs should be contemplated, as well. OTOH since they're trustless you don't need to make dishonest behavior prohibitively expensive.

there are no addresses, assets bound to utxos

But I’m ok with that. If I could mine a block I would put whatever I want in it 🤓

im against adding xcp here because of the extra friction

you can mitigate that with tx chaining

you can send to many addresses or bind to utxos

i dont see a reason for the 2nd to have an xcp fee

My position is that any use-case which has a disproportionate affect on the network should incur fees.

you could say that about everything

...

sure

any feature adds computational cost

we live in an age of indexers without native tokens, you want users to chose counterparty not add a layer of friction

Well then is totally different from dispensers. I wouldn’t call it a replacement, but a new way

yes it is totally different

but in this case the change being contemplated breaks Counterparty's architecture in a new way, as a direct result of which performance takes a massive hit.

not worth the cost of friction

I understand your opinion; I have mine

I think at least we can all agree that dispensers should not be unlimited time for free

wasnt too long ago we had a contentious fork because of wanting to add xcp fees 😛

I've said over and over that my opposition to that fork wasn't because it added xcp fees

im just saying in general, not you specifically

its a hot button topic

Oh sure.

the goal of utxo binding is to eliminate a giant computational cost (dispensers) so on net you still come out on top keeping it free of an xcp fee

You will have to track utxos now right? So is not free either…

this is all assuming there's a future in which dispensers are free

which I disagree with

def not free

on net if it results in dispensers being sunset then it will be

My thinking is pretty straightforward: this is a fee for using a feature which will tangibly degrade the network; that feature does not yet exist and therefore the fee isn't prejudiced against any specific use-case; that fee will be charged to existing users of the platform and therefore will not prevent new users from joining the network. the fee will be denominated in XCP, Counterparty's native currency, which was created in a provably fair and decentralized way. liquidity for the XCP will be provided by the feature itself, with the XCP/BTC trading pair.

I think the “assets available at an address” is too cool to be replaced lol

its not hard to imagine the conversations if announce a new version with XCP fees on dispensers

you dont have to sell me on XCP, ive been living with it for 10 years

i understand the pros and cons

I'm not selling you on XCP or anything, I am explaining why I think this is a reasonable place for a fee.

i get it but i also understand the reality of the landscape we find ourselves in

its a good conversation to have regardless, would be interesting to get others thoughts

this is what was tough about the contentious fork drama: Counterparty _does_ have a free-rider problem; that free-rider problem is partly because Counterparty isn't sticky; Counterparty isn't sticky because it has nonsensical tokenomics.

The above ofc has nothing to do with charging fees for numeric assets

psbts create a huge opportunity for whoever wants to build that marketplace

people hear the word "fees" and think "friction". it's not that simple. fees can (and generally should be) dynamic, so that fees are very low as long as usage is low. and there are ways of making fee payments transparent to the user. but not all features have the same computational/storage cost, and BTC fees aren't enough for supporting heavier transactions

the first question someone will ask is “why doesnt ord have this problem?"

or any of the other indexers built on top of it

you’ll need a VERY compelling argument

sure.

IMO xcp fees make most sense for features that are unique to counterparty

like issuing named assets and sweeps and dividends

applying them to basic functions that other bitcoin based tokens can do without a native token fee would be just shooting ourselves in the foot

nothing better than having to beg for forgiveness for adding fees denominated in a fairly minted currency for a feature which has a direct impact on node operators, while everyone cheers on 'governance tokens'

this is a self-created problem because we've been crying mea culpa since day 1 for having created XCP in the first place.

yes so lets not exacerbate it lol

that's not how it works

You don't change the narrative by conceding a faulty premise

it wasnt faulty at the time

things change

its not conceding anything

no one is asking to remove XCP fees from named issuances for example

or sweeps or dividends

lol, that's because those fees were added without asking anyone

all the more reason to ask for them to be removed

that is not how human psychology works

sir

🤷‍♀️ idk what to say. I am fine with disagreeing on this point.

hahaha me too

better to get more opinions

Imagine having to pay XCP to do a send

would be terrible

or make an order

better analogy in this case

Keeping fees to a few functions is more sane

There is zero user benefit to adding more fees

by this same logic dispensers are perfect.

How does a user benefit from additional XCP fees? If that were the case, we should put fees on every function, and increase existing fees 10x

even better

the network exists for the users, to be sure, but the whole thing breaks if there isn't a virtuous cycle between the platform and the users.

(and to jump to the conclusion: yes, the platform is basically broken as of 9.61.1; and yes, I directly attribute that to Counterparty's broken tokenomics)

My opinion would be that fees should only be on functionality that has direct alignment of incentives with users.

I think this is a good example of when a fee directly aligns. https://github.com/CounterpartyXCP/cips/discussions/127

@herpenstein how about dispensers

I mean, there is no direct link between the XCP token price, and the "platform"

you’re making xchain’s argument

*that* is broken tokenomics.

stamps are a burden we need an xcp fee on numerics

network cant handle it

they weren't a burden

that was not a real argument

and neither are dispensers to the users

and xchain makes reverse argument

lol, you surely understand why that is not apples-to-apples, but whatever.

“dispensers just fine here"

if removing all barriers to entry were the best way to guarantee success then we'd all be using Open Transactions.

everyone is using ord

there are cultural reasons for that

and lower friction reasons

I'm just pointing out, that pumping XCP, doesn't fund operations, and will make it more expensive for users

It pumps the bagholders

_pumping XCP_ is no one's goal; coordinating XCP's utility with the network's usage absolutely _is_ a goal.

what if it was just a higher btc fee for heavier txs

accomplishes the same thing and doesnt pump XCP

Then Counterparty as a platform still atrophies.

If this were any other system

we would criticize attempts for scammy tokenomics

XCP is already deflationary, name registration, subnames are burning XCP

etc

if name registration isn't 'scammy tokenomics' then tying fees to computational load certainly isn't

xchain argument

it just isn't joe

i don't know what to tell you

numeric issuances don't break Counterparty's entire transaction model

At least with name registration, there is a legit reason, antispam to prevent mass registration and camping

thats how it looks, most people dont understand nuance here

you keep flipflopping between how it looks and what it is. If you enjoy debating for its own sake this makes sense but it's not arguing in good faith.

no i think ive been consistent, im agreeing the argument is different from xchain argument but im not agreeing xcp is the solution

okay that's fine

and im just pointing out from the surface it looks just like numeric asset argument

so you’re fighting an uphill battle

What do you feel needs to be "paid" for, or a fee charged for, in principle, so I understand ?

and it does add friction, anyone thats used counterparty can attest to that, its one of the main reasons stamps uses numerics

in addition to what is done currently

we can add tx chaining so that xcp purchase and utxo binding happen in the same block

purchase from where?

The main problem with dispensers is in the backend. For users, they are great. That is a problem we need to figure out how to solve…

Thinking that maybe we should just require dispense transactions to include a CNTRPRTY message and that will solve the backend’s performance issues and there will be no need to add a fee to dispensers.

im def onboard with that

adam mentioned that to me before. but dispenses aren't even counterparty transactions...

I think you can do this with an onchain btc/xcp market.

people need to send to dispenser from a counterparty aware wallet anyway

so having a message included to make it valid makes sense

and that would put them on par with an order

as far as computational cost

As I've said at length, transactions which _by design_ (*not* numeric issuances e..g) have an *outsized* externalized cost should be more costly.

It's great that dispensers onboarded so many users, but they almost broke everything.

But there is zero link between the platform, and XCP burned

well we’re talking hypotheticals here anyway, why not wait to have the conversation until after you know what that cost is

because it came up...

Burning XCP, doesn't pay to run a node

that isn't the only math that matters here

bitcoin node operators don't get paid to run nodes, but they do. but if btc were worthless, they wouldn't.

I mean, are you worried about too many txs to process?

Aren't the limits of btc L1 low enough to keep it reasonable?

Then we should make them. The simplest possible way, maybe even allow clear text CNTRPRTY by itself in the op return would be cool

should add a message id

make it clean

I am worried about the fact that there was a consensus bug exploited in the wild for 2.5 years and no one caught it. I think the reason for that is that users of Counterparty don't know they're using Counterparty for the most part and astonishingly there seems to be a consensus that that's a good thing.

2014-2015 users are a much different breed than 2024 users

Well but the arc enconding is an issue for anyone not running cp aware wallets. Clear text can be much simpler for wallets to implement. And no id could just mean “counterparty read me please”

How does fees figure into that?

you lost me

Some specific exploit found?

there are more bitcoin nodes today than there were in 2014-2015

https://t.me/xcpdev/8309

XCP has value

Already does

the truncation issue. there was also a _divide by fucking zero_ error which was caught by the generic exception handling.

I'm not a dev like you guys

but I'm not getting it

XCP is already deflationary

Even though I don't own a bag of XCP, I plan to run a node

XCP's value is untethered to the network usage and there is a strong desire to keep it that way. My argument is that that's what nearly killed Counterparty.

If XCP were 1k a token

what would that fix?

I am not trying to be rude but I'm at a loss for a new way to state my view.

Yeah, I'm just trying to understand