The protocol almost never changes, so spreading out the cumulative effect over many months in a staged release should at least be up for discussion

I think the proposed change is good because it will ensure the api doesn’t allow dispenser creation when a buy is already present in the mempool

I said that and got pitchforked. Good luck.

Soooo

Whats the final decision

Undeerstood

I thought the main issue with dispensers besides being able to be rugged is the parsing load time it adds to setting up a cp node.

By doing nothing, everyday that passes will continually add more time for parsing a cp node.

there's no "final decision". there's a discussion on GitHub.

Once caught up, it’s not a big deal.

I will be attentive as soon as there is a final consensus.

Sounding more like crowdsourced instead of opensource.

Do you use a CD player to play a cassette. No. You use the right tooling.

Double deck, AM/FM CD combo

+USB

With a dongle adapter.

i was gonna say no, leave it as it,
but maybe its ok.
the same issue arises tho
"bro i swear i sent you 0.1 btc to buy XYZ, i didnt know i needed a prefix msg"
its just easy to set stuff on an address and keep as it, i dont see how much changes
I didnt read the proposal just a few msgs in this chat

they need to relax a bit

We shouldn’t worry about users who are using wallets that are not aware of CP.

There is AFAICT one use-case which will be eliminated: triggering dispensers from non-Counterparty wallets. The downstream consequences of maintaining that use-case are serious.

dispenser are prone to rugpulls. so im not a fan of that.

the more i think about this statement, the more confused i feel

so this would also fix dispenser scammer issues too? Huge if true

yes, this is the thing which has to be fixed, cause selling XCP or assets, pay higher fee and send yourself the btc before confirm. that was always the problem with them, thx for reminding me

The delay for closing logic could be adapted to prevent rugpulls.

but that can be fixed without a change in the protocol.

there's a number of different ways to lose money with dispensers. this would eliminate some of them but not rugspensers, which are a *feature* of dispensers.

oh i didnt know

"rugspensers" lol

Unfortunately not completely. But would make it less likely unless manually performed

No, that's wrong. The close delay eliminates one type of attack but doesn't solve the issue completely. It can't be solved as it's how dispensers work.

Yeah man IDK. This wasn't on my bingo card but apparently it's a use-case.

Can you extrapolate the word ‘it’?

Triggering dispensers from wallets that don't support Counterparty

I'm *all* for graceful transitions! But drawing things out in the manner you're describing won't help. If Counterparty wallet devs won't make a small change to their software over the course of a couple of months, then they won't do it in a year. And users triggering dispensers with Electrum will be in the same boat.

What I was thinking was (1) adding support for an optional compose_dispense() (using OP_RETURN etc.) and (2) having compose_send('BTC') guess whether the TX should trigger a dispenser—if it does, turn it into a compose_dispense(). Then we can track to see how much adoption there is of the new method etc. and remove the broken method later.

on stamps or something? xcp is pepe rares all that stuff. what else using? bcash ? lmao

if you use a generic bitcoin wallet you can trigger a dispense by sending bitcoin to a dispenser. you can't do anything with the dispensed assets but you "have" them

It is better if you consider "dispenser" safe 99.9 % trustless. if the address source has a CLTV, that resolves all the rugpulls.

You do not require a change in the protocol, you just need only check from the frontend that the source address meets that condition.

You know whata CLTV is right??

Time lock

ah yes thats not good still - im convinced most doing these scams would continue doing it manually if still possible

Well that is an option, there are other more complicate ways to prevent Rugpulls..... but they require more work on the part of the frontend.

you're just making it more difficult not eliminating the counterparty risk. the way to eliminate the counterparty risk is trustless atomic swaps

but you will always require the frontend to validate "certain conditions".

we have 99.99% trustless atomic swaps, forcing addresses to have a single utxo.

there's a qualitative difference between "it's difficult to steal someone's money" and "it's impossible to steal someone's money"

0.1% of failure is that the addres that sells the CP assets make a CPFP

The design of dispensers is fundamenally *not* trustless. Rugpulls will always be pretty easy to execute for anyone running a dispenser, and frontrunning will always be a possibility. The proposal under discussion, however, eliminates a number of other very significant failure modes for dispensers as they are currently implemented, and makes it straightforward to add extra sanity checks to reduce the frequency of loss of funds.

i think having a way to buy and sell xcp and xcp assets for btc without a chance to lose your funds to a scammer is most important thing to me

that's atomic swaps

and it's coming

ive had friends i onboarded ragequit counterparty from it

attaching assets to utxos?

yeah it's seriously not cool

Again, the change being discussed eliminates one use-case: triggering dispensers from a wallet that doesn't support Counterparty (and of course from which you cannot see or do anything with the dispensed assets)

Of course keeping things the way they are makes people lose money in all sorts of ways but apparently as long as it's familiar people are okay with it

i think its not possible but like the current dex orderbook - if btc could be in it like pepecash its now rugproof, if atomic swaps brings similar experience it will be gamechanging

Yes but stampverse and ninja can continue by simply hard coding the prefix into the buy button

do you have to make this dispenser change to make PSBT and Atomic Swaps work? if not, why not revisit it again when the community is *maybe* and *hopefully* more reliant on those? instead of the other way around?

Xcp.ninja would be same

oh boy, believe me people will look for new ways to lose money.

new ways to lose money are bad, old ways to lose money are good.

Jajaj

because this is a *bugfix*. conceptually it has to be okay to fix bugs

Has anyone tried to do LN in CP? That would also solve many problems.

in this way we can have all trustless.

this "bugfix" is extremely controversial if you cannot tell.... usually things this in depth were done in the past with formal CIP's

as Adam said only 2 CIPs were ever accepted

@jp_janssen @hodlencoinfield thoughts on this?

and dispensers wasn't one of them so technically they shouldn't have been deployed 😉

...and they didn't reference any actual engineering

From my point of view, CP should take advantage of the thousands of Bitcoin wallets that exist and allow the possibility that other users of other wallets can interact with CP.

I am also not a fan of the assets attached to utxos.

but i cant change that

If you want it, just do it.

You don't get to have it both ways: either the CIP is a specification or it isn't. if it is then the the absence of the prefix is a bug since the prefix is how counterparty txs are identified and not including it wasn't part of the CIP.

If on the other hand the CIP isn't a specification then you can't fall back on the process when a change is contemplated that makes you uncomfy

that is literally the basis of the discussion. but there are real consequences to this way of doing things and no one is engaging with them but rather just sticking with weird generalities like change is bad/scary and i like the way i lose money today

Counterparty isn't Bitcoin and there's no magic in pretending that it is... it breaks shit.

Xcp card Explorer/market place. Continue adoption

you're not engaging with technical realities and I don't know why.

With the assets attached to the utxos, we will make CP become a fully Bitcoin network with a side database tracking the movements. .....

yeah utxo binding does the thing that dispensers can't.

but that's all to the side.

But good practices in the way addresses are built and users and utxos are managed too... can solve that.

the current hysteria is about people not using Counterparty using Counterparty.

and as I said above, has anyone tried using LN in CP? That solves all the current problems.

And no one is seriously willing to engage in a discussion of technical tradeoffs for reasons which are completely beyond me.

I have a theory of development, I think that talking about tradeoffs is tiring that we avoid it because we are human. . but it is always necessary put ont he table and documebt these tradeoffs..

they are documented on github

it throttles performance and adds code complexity in the part of the code which was rife with consensus issues

I only found a deleted doc file that talked about why CP should use LN...

but no analysis of why and what it solves.

bromides like "Think of the [non-Counterparty] users!" are completely unhelpful.

@theogoodman your thoughts on this?

TIL this is not a discussion

for the sake of understanding I'd like to ask in relation to people that use counterparty with electrum - presumably they are using this tool https://jpja.github.io/Electrum-Counterparty/ (or something like it to generate the counterparty compliant OP_RETURN messages)

If the dispenser change is activated, and 'pure bitcoin' transactions no longer trigger a dispenser, presumably this tool (or it's alternatives) could implement a way to BUY from a dispenser by sending bitcoin with a correctly generated OP_RETURN. Is that correct?

It must be taken into account that the bitcoin network is not simply a node, also the way addresses are created and utxos are managed is the other 50% of the bitcoin network. and that will happen in wallet providers, dapp creators. and platforms.

wait till some others weigh in.... xcp community takes a while to zero in on things (and only really serious people interact in github) - its a friday

@davesta if you can't converse at an even moderately technical level about the proposed change that's perfectly fine but pretending that hearing things you don't like or don't understand aren't part of a discussion is pretty absurd.

CP also depends on that, if there were better practices on the part of dapss and wallet creators, most of the problems are solved.

i get it. you disagree with me... im interested to hear what JPJA, Theo, Joe, Jdog and others feel about this

You are concerned about people using software that doesn't support Counterparty or doesn't upgrade. I get it. But you've said nothing helpful beyond that.

my memes will make someone laugh

Dare to dream.

this is a community that prides itself on decentralization and no doubt thinks that shitposting contributes to decentralization, but unless the software is performant and free of consensus issues you're better off using a regular web app

if implemented JPJA could simply upgrade the Electrum tx generator to include the create_dispenser prefix... doesnt mean you wouldnt be able to generate XCP txs manually... it means if you wanna use Electrum to buy from a dispenser using a good ol BTC tx (no OP_RETURN) it wouldnt work and the btc would go the disp addy without a card being dispensed

Yes, you are correct

oh man I mean it's great that JPJA built this tool but why aren't people demanding more of the *wallet developers*?

Because people don't realize that dogshit node software totally disincentivizes people from building tooling around the node.

it's not a defining feature of Counterparty that the best mobile app it has was last updated *checks notes* four years ago

what if JPJA disagreed and didnt want to update to create_dispenser ? that would be a fork of the protocol?

... assuming people ran nodes of previous vers

no (and, to be frank, if you have to ask that question, you shouldn't be opining on technical matters)

right but as long as you control keys, you could it later on, but yes i understand. that is a big question to ask to be able to only dispense when a string is attached, while the btc is sent and spent anyway and not refunded... and even if its refunded it can go back to say an exchange wallet automatically which wont be deposited to the right persons address

is a dispense a counterparty transaction in your opinion?

huh i see

I don't have a strong opinion in either direction related to this change - I do however think it's safe to believe that the vast majority of individuals currently using dispsers with 'pure bitcoin' transactions are doing so with the technical knowledge that they would need to use these OP_RETURN tools to continue with any usage/control of the token they are buying. So the reason i clarified this is to point out that the version of using "non-counterparty wallets" we are talking about (e.g. electrum) could still in the future be done using these types of work arounds.

i have drawed how works our atomic swaps, just tell me if this is a trustless way or not.

any Bitcoin wallet can add support for Counterparty transactions, but with this change, if they don't have support when you do a normal btc send to a dispenser an asset won't be dispensed.

that's it. the change is: if you want to make a Counterparty transaction you have to use a Counterparty wallet. it's a mind-boggling thought but whatcha gonna do

I'm not a tech guy but it seems like this would be a good change as we could then use a native xcp currency like gas or whatever to move xcp assets without having to use bitcoin? is that the overall idea

the idea is just that counterparty transactions are not simply bitcoin transactions... unless you want trigger a dispenser. The proposal is to make triggering a dispenser a Counterparty transaction, too. In addition to the architectural benefits there are lots of nice downstream benefits, too.

✨ like allowing multiple dispensers on a single address ✨

you can already do that

setup multiple dispenesrs dispensing different items on different adresses.... i'll agree the UI sucks to display that you can buy many things from a single address... but, functionlality wise... it works.... one BTC payment to one address can trigger infinite dispensers/dispenses

Maybe I'm missing something. If a dispense is triggered by a simple btc send then how do you specify which dispenser you want to trigger?

price

That's what I'm trying to say... one public key can manage multiple dispensers.... but the UX/UI sucks at displaying it well.

BTC payment triggers all dispeners below BTC payment price

okay let me correct my previous statement: "like allowing multiple *independent* dispensers on a single address"

A public key can have multiple addresses....

https://xchain.io/tx/614679b4f6330b7c522a5e57b48b2f2d9eda6da03ab750abcdeaecf895005727

one BTC payment... to one address... .triggered 60 dispeners

then the seller risks dispensing assets they didn't intend to, right?

with the current design, it's not possible to sell two different assets for the same price e.g. with the same address, without selling *both* at the same time, every time

different prices.. and warnings in wallets about setting up multiple dispensers on different addresses

If done this way, the source addresses would only become dispenser identifiers.

what if I have two dispensers price X and price Y, X > Y. If buyer sends X btc, does he get both the X- and Y-priced or only X?

BTC payment triggers all dispeners on an adress below the BTC trigger amount.... so, could sent BTC payment to Y and get both X and Y if X price is lower..... people do this all the time currently,,.... setup a card they want to sell at a top price... setup a bunch of bonus tokens they get dispensed at a lower price..... one BTC payment buys them all

Okay but then as a seller I really should have one dispenser per address

correct... you managed to find one use-case in the CURRENT dispensers design that does not work..... tho, simple solution to selling 2 tokens at 2 of the same prices is setup 2 dispensers on 2 different addresses.

unless it's my intention that the highest-priced dispenser triggers all lower-priced dispensers.

If the goal is to make an address have multiple dispensers, you have to make "buy dispensers" native to CP.... but then if we use atomicswaps, dispensers don't make sense.

I'm not arguing that your design doesn't have some benefits... .it does.... but, it cripples current dispenser functionality by removing the ability to pay with just a normal BTC payment in a normal wallet.... this is a change I am against at this time..... You can add other things to counterparty without messing with dispenesrs now.... if you do mess with them, definitely make stuff backwards compatible so ppl can continue using them as they have for years... Just my $0.02.... i've left my thoughts on the github issue... https://github.com/CounterpartyXCP/counterparty-core/issues/1670

Initially, I'd be concerned about people losing funds.

I don't immediately upgrade freewallet all the time

I think dev should focus on better solutions that remove the need for dispeners.... atomic swaps being supported would quickly move traffic from dispeners to atomic swaps... at which point, then would be more appropriate to depreciate or modify dispensres.... but not right now since they are what has onboarded most ppl to CP, and are the most used feature in CP

imagine how some rando would feel, if they fired up freewallet after a year, and essentially rugged themselves on a dispenser

@ChiefSamyaza we're absolutely going to work on that, but the goal is different

Is there a way to prevent that from happening?

Lets focus our energy it atomic swaps and if the people want more fancy dispensers then we work in that

?

this isn't fancy dispensers

*this is adding a prefix to dispenses*

call it what you want

it means ppl lose funds

Hopefully I won't be muted or banned for discussing this here

people currently lose funds constantly

cuz they do what they normally do... send BTC... except now in counterparty that BTC send wont trigger a dispense

Well to have multiple dispensers at one address is cool.

it's a downstream benefit not the reason for the change

it's kinda weird how literally zero humans engaged in this discussion have addressed the motivation for the change, which is outlined in the GitHub issue?

which no one has actually engaged with yet despite so very many words

I know that performance and consensus are for nerds but if someone could actually engage with the reasons being given for the change that'd be really cool.

what are you talking about? I asked you for info on why the change to dispensers... details on the "consensus issues".. asked why this change need to be made now.... and havec not heard back anything really worthwile.... .yet meanwhile, i see multiple community members objecting to this change

My concern isn't peformance

but people running old wallets getting rugged

Adam replied to you on GitHub

Is there another way to do this, that wouldn't break old wallets?

no.

bigger question... why is this change necessary NOW?

why must this change be forced NOW?

The change is being "forced" now because there's a protocol upgrade required to drop the addrindexrs dependency from dispensers which was unfortunately added last year and this change is technically straightforward and thematic with "clean up dispensers"

every mandatory upgrade breaks wallets.

there were three releases last year, two of which were mandatory upgrades.

well i am off. Move these conversations to Github like civilized engineers, on the round table of asgar..... I will go there when a decision has already been made.

Have their been previous mandatory upgrades that could lead to users getting rugged? I know adding features is one thing, but this seems like a big deal imo

Every mandatory upgrade is potentially a network split, so they can all result in loss of funds.

so your prepared for a network split and not concerned with loss of funds? You prefer to push out this "mandatory" update which could result in a loss of funds and a ledger fork (something we ALL want to avoid).... ALL so you can push out this fundamental change to dispsensers..... just want it to be clear, this change is being forced, ppl in community are raising concerns about lost funds, and the response is basically... we're moving forward.

you released 2 mandatory upgrades last year lol

I didnt' remove functionality

we are playing word games here Evan

no we're really not

which is why I choose to engage with Adam.... your discourse with me, and how you talk to other developers is quiet off-putting

that's fine, then engage with Adam on GitHub.

This is not the technical development chat.

agreed... however some things need to be brought up in main channel occasionally... like a fundmental way to the way dispeners operate. I've said my piece on github.... now i'll wait n see where the chips fall in a few weeks.... back to vacation.

And you say that I don’t understand how counterparty works…

> the response is basically... we're moving forward.

source? @ChiefSamyaza, literally nothing is being forced. the only thing that has happened is that I filed a GitHub issue, and then Evan and I proactively reached out to numerous community members to point them at it. you've been terrified about us forcing protocol changes for the past five months... because that's what you yourself did. not because of any behavior of ours.

The proposed change absolutely does involve removing functionality, a fact that we both have said that we give significant weight to. But the quality of this discussion has been extremely disappointing. People are rightfully worried about loss of user funds... as far as I'm concerned that's generally not an option! As I have said over and over again, the users come first. *But* almost no one has even addressed the actual benefits of the proposal, which are substantial, and a large number of people are completely oblivious to the fact that protocol changes like this are perfectly normal and safe. Yes, wallet devs would have to patch their code during the protocol change window. Yes, people using non-Counterparty wallets to trigger dispensers would have to stop doing that—they need to do anyway, because it can already lead to loss of funds! If that's too much to ask, yeah the community *does* have bigger problems than the architecture of dispensers, or, for that matter, the lack of atomic swaps—which will also be a protocol change and will require wallet devs to update their software.

wow... so I forced protocol changes now eh?.... like the XCP fee on numerics that I screamed about for a year, but never forced.... WTF bro... lo... yeah, not much point in being here anymore if even the co-founders are pushing that narrative... yeah, best I dip out now... l8r g8r

As a non-technical user of the platform, I don't see any red flags here. Upgrades to old systems are a necessity. I have faith in the community to be able to relay any pertinent information to new users (of which there are few). And faith that wallet devs will make the necessary adjustments to ensure minimal user error.

I've never bought from a dispenser using a "regular" wallet. Electrum, for me is used to sweep private keys and consolidating UTXO's only.

THIS is the biggest UX impact. The final fundamental reason for the dispenser itself, the DISPENSE. 🤯

For the new record, these 2 weeks / 1 month times should not be set in stone.

We should try to emulate some sort of signaling for “controversial” or just “people can lose money” upgrades.

Isn’t Counterparty a decentralized network? How can we force other nodes to upgrade for changes they don’t agree with?

you can't force nodes to upgrade. every forwards-incompatible change can result in loss of funds (though the likelihood increases if the change is controversial and if the network is decentralized)

Everyone uses an explorer to buy from dispensers… don’t see why you can’t just have the warning there, loss of funds if you are using a non cp compatible wallet.

You can. XChain already says you can't send funds from a taproot address. same principle.

@XCERXCP this is a very good point 👆 it's not like these dispensers can just hang around for six months. you might be able to use Electrum today to *buy* from a dispenser, but you can't use Electrum to find the dispensers in the first place.

No one’s writing down dispenser address in a note book for the future. 😂

No one is debating the codebase part.

Some of us have been very specific about the usability concerns.

Something that couldn’t be simpler, and is the MAIN way to get onboarded to Counterparty, is being changed. By breaking the old way. By adding more steps.

This is NOT a subjective opinion. This is basic usability (engineering).

The bigger concern here, maybe, is not realizing the impact of this change.

Actually, "Send BTC from a non-CP wallet and receive a CP asset which my wallet doesn't support and then import my seed into a CP wallet when I want to do something with that asset. Oh and make sure I'm not sending from a Taproot or P2WSH address or I lose my money" being the simplest way to onboard *is* a subjective opinion, and pretty obviously disputable.

Not necessarily from the onboarding perspective.

Fren, just send BTC to this address. You’ll have XCP.

This is FEATURE, not a bug (IMO)

The bigger concern is hindering the development of CP forward so we don’t fade into oblivion.

This entire argument is simply about CP users who are not using a CP wallet.

Do those users warrant an endless increase in parsing time to set up a node.

For what it’s worth, on stampverse we use standard web3 wallets and generate cp txs and manually convert them to psbts so the txs can be signed so even if web3 wallets don’t directly support counterparty txs, we can support web3 wallets and ensure you can buy/sell/transfer

But if you ever want to sell your XCP, you need to use a CP wallet and import the key

Or use CP in any other way besides buying and holding forever

... and you lose your corn if you send from taproot or p2wsh

I think using existing wallets that have users is the next big step. Your api updates for creating PSBT instead of standard hex txs will go a long way to getting platforms integrating

how much parsing time does it save? and why couldnt it be done at a later time?

Ideally someone could print a dispenser address and details and tape it to a wall. What then?

For dispensers, since theirs no prefix, CP needs to search every bitcoin transaction. So if I’m not mistaking, everyday that passes by, every bitcoin transaction will need to be searched in the future and there is no way around that until the heading is added.

Yes, parsing time grows in the number of txs

it puts a hard limit on optimization.

The only valid concerns are about old wallets not updating and users losing funds. The other arguments involving using non-counterparty wallets to exploit a broken feature aren't

And it can’t be undone..

It will always be required in the future during the dispersers lifetime as is

you need to check whether every transaction triggers a dispense.

Yes, so I’m saying, there’s no way around that and everyday that passes is another day where all txs need to be checked against

Yep. It makes every Bitcoin transaction a Counterparty transaction.

So until we can get a header, that will always be the case and the parsing time will exponentially grow

how much time would you estimate... id assume dispenser tx's account for less than 0.01% of all txs..... would you then also have to record all the previous txs and open ones before prefix? or just use the data prior from sifting through all the txs before the change was implemented... wouldnt new nodes need to sift through the data pre-prefix to find all the 'old' dispenser txs?

sorry not TECHNICAL still learning

It doesn’t matter if there is 1 or 1,000,000… every BTC tx needs to be checked against

no, as with burns you'd hard-code a list of historical dispenses. that list could be independently verified by using an old version of the software if someone wanted to.

True for tx’s in the past. The node could handle past transactions as it does now and inspect all new transactions as they come.

so whats the time estimate then? couple hours? days?

Counterparty, the protocol, is just a consensus on the interpretation of messages written in Bitcoin.

With BTC transactions.

Wallets clients, are private key managers. Not validating nodes. These rely on validating nodes through an api.

The protocol is not backward compatible, true, as is being repeated. Consensus. Fundamental. “Sacrosanct”?

But the wallet is not the protocol for Counterparty. The wallet just allows the writing into the BTC transaction. WRITE. The READ is delegated to a (as much as possible) backward compatible api.

This is no traditional (centralized) “blockchain”. This is the only true timechain, “imo”.

Before most recent optimizations parsing took 2-3 weeks

Adam and especially Ouziel have got it down to 1 day with kickstart. however it's a tx log so it just keeps growing and if we can't parallelize then syncing time will continue to increase in perpetuity.

? Comparing to a literal authority?

here's a flamegraph Adam posted in the issue. is_dispensible takes all the time...

so is the thought that when psbt and atomic swaps drop and new interested devs are looking at running a node it should be the best it can be to influence new projects and folks to build?

vs having psbt and atomic swaps when it takes 3 weeks to set up a node from scratch?

Elaborate

the idea is that if you want good tooling you need good node software (or a giant piggy bank)

no one wants to build on top of bad infrastructure. It's not a particularly profound point. And a performant node will *increase decentralization*.

To me “they” do.

There shouldn’t even be a “they”.

THIS is definitely part of the issue.

Ok yeah, I’m also a dev.

Also if you are NOT in favor.

(Man too many messages I cannot ignore, sorry for the spam 😭)

1 day to get a node up and running sounds reasonable.

A change in logic for processing new transactions after reaching the tip, could help prevent a protocol change.

Next time we converse about code, link us to the code in question please.

it took an absolutely heroic effort to get it down to 1 day. it will increase in the number of txs without adding the dispense prefix

Jus wait for zk proofs and bitvm wave

Not my experience. The seller has the decision. I’ve successfully bought multiple assets from a single BTC send.

Point was Musk moves fast and he’s on top for a reason.

We have a group of world class Bitcoin developers wanting to move the protocol forward and we’re arguing about users who likely don’t even exist.

This is what a bottleneck looks like. We can't make it go faster without adding the prefix. Sorry.

I think one of the main issues here is perspective.

I’m thinking a lot about the buyer use case. It has the biggest weight here imo.

Right

Exactly. And everyday that passes is 300,000 more txs to scan.

and atomic swaps will slow things down again. there are real tradeoffs here which need to be engaged with.

And with the recent upgrade, you can dispense to multiple addresses in a single BTC transaction

And who’s that buyer?

Does anyone here know of anyone that uses CP but not a CP wallet?

Me

But you have a CP wallet?

This is possible now.

…

JPJA ;)

I want to know a user who uses CP but has never used a CP wallet…

Find me that person, they don’t exist.

Adam and Ouziel were amazingly able to get a 20x performance increase without making a single protocol change. If we want to future-proof Counterparty to ensure users can still sync their nodes then we need to parallelize the is_dispensible call which means we need to add the prefix.

Well, I have used CP wallets before, but now I have moved everything to okx.

…

Also,

If you are not.

you trigger every dispenser with a price less than or equal to the amount of BTC you send. Adam is saying that this change would avoid that.

Wait… but aren’t CIPs… I’m confused.

We should be better than this.

Let’s revert recent “authoritarian” (imo) moves, learn, and move on.

so with prefix you are only reading the OP_RETURN included txs? without prefix you have to read all btc txs? .... because only the Dispenser action relies on non OP_RETURN functions?... forgive me if im interpreting that wrong

nope you got it

and they said i wasnt allowed to OP anymore

Simple

Yes, it’s insane we would want to keep it this way and keep adding parsing debt

it makes sense... it just how to implement it in the best way for the community... you wouldnt want a single wallet not upgraded in that case

again, that applies to every mandatory upgrade

if two wallets are running incompatible versions they're writing to different networks

It's not a matter of degree. counterparty doesn't fork so there's no reorgs

what if the upgrade was bundled with atomic swap and psbt functionality... so if the user is 'mad' dispensers changed you can give them some good news too?.... why this order of prefix first then atomic swaps/psbts? how would you invite users to test both?

how is that not more coercive?

oh its already coercive "were moving forward"

what if there are technical reasons why it would be better to roll out this change before atomic swaps?

is there?

I am not sure beyond code complexity and eliminating one performance bottleneck before introing another. Would leave that to @teysol to opine on.

True.

There are goods and bads. There must be a place for discussing these before wasting resources on an implementation that will cause (unnecessary) contention in a decentralized protocol.

Or is centralized. Which for sure many don’t care. I do, as much a possible

User mad about not using a CP wallet lol cmon man

right, the theoretical user wouldn't have a Counterparty wallet so why would he care about atomic swaps lol

Who are these mysterious buyers who don’t use a CP wallet and only buy XCP lol

Never sell, never send, nothing

As I wrote above, this is the workflow that people want to preserve at the cost of performance: Send BTC from a non-CP wallet and receive a CP asset which my wallet doesn't support and then import my seed into a CP wallet when I want to do something with that asset. Oh and make sure I'm not sending from a Taproot or P2WSH address or I lose my money

that was never the discussion, it was about user using the tooling other wallets provide for UTXOs, RBF and CPFP because the protocol allowed for a simple btc tx to dispense things... and when its a large value or a buyer was scared of rugspenser mempool snipes - or that the main wallet the community uses (FW) lets users download and use any version they want (even the 4 year old version).... which if not updated would cause loss of funds

you dont technically lose it because if future functionality is implemented for those addresses, they can be recovered

Who's going to implement that functionality?

its been on the docket a while: https://forums.counterparty.io/t/ordinal-envelopes/6504

i understand it more now at least, thank you

being on a docket is not the same thing as being implemented.

Everyone is checking dispensers in realtime when buying…

The explorers need to put users on notice. If they can’t read, it’s their fault.

no one said this.

and as @XCERXCP pointed out, the problem is *not* old wallets updating. the problem is explorers, because that's where the dispensers are actually listed.

i interpreted this as "we are going to do it" .... "were moving forward".... you know ill just go enjoy my friday... do your thing... ill just write disclaimers on docs if needed when it drops

doesn't matter. someone might've said it and that's enough and I'm angry at them.

so TBC you put words in Adam's mouth and then got angry about it right?

The Sock Master currently has tiered pricing across many Rare Socks to facilitate buying multiples and tranches of socks of varying rarity at higher price points…

I’ve used that feature to build up my Rare Sock holdings.

Planning another buy soon.

It is still not clear to me if the performance gain is parsing at kickstart or follow. I think is kickstart because v10 still doesn’t do block by block asset conservation validation.

A kind of big deal, which was warned when the no-updates change was done without compromise.

And there are other changes to consensus, database and api. Is not 100% backwards compatible.

I had to get into the schema and add some columns to keep it working seamlessly for xcp.dev. Something I wanted to avoid by communicating my issues in GitHub… but truly enjoyed working on 😍.

ALL POSSIBLE by the AMAZING work led by Adam. And Ouziel has been 🔥🔥🔥. Counterparty is beautifully simple. ❤️❤️❤️

How did you interpret it? "We are moving forward in the conversation?"

">" means he's quoting someone else lol. c'mon man.

But the jobs done. Down to a day. Take a bow, don’t panic.

Oh he's quoting from the GitHub

I think if the person who got the 20x performance increase is telling you you should be worried that ought to carry some weight. no one wants to take any bows.

Oh how *stupid* of me

Curtsy, whatever.

As a regular buyer from dispensers, I always check xchain live first to ensure there isn’t an unconfirmed dispense already pending, then I use freewallet, or perhaps occasionally rarepepewallet to send.

I have never used electrum to send funds to a dispenser.

So this just seems like an update needed for free wallet and a notice on xchain not to send from other Bitcoin wallets.

bytesdust.com already tell the user if can buy a dispenser, the user cant copy any address, just calculate how much XCP do you want, then sign and send the transaction.

Only cool thing Biden does is say cmon man

I sell my project every chance I get.... hahah

bro said, 🚜🚜🚜🚜

Exchanges when people send BTC to their addresses while forgetting they had open dispensers?

Almost!!

CIPs

ISSUE 1670

Pretty much this.

Will check it out, thanks

YES!!!

My suggestion: add it in cleartext. Just like stamps do, CNTRPRTY or XCP in the op-return. That’s it.

This is 100% doable.

Okay I think I have caught up with all the discussion now.

The edge case concern I can see is someone waking up after a long period, and deciding to use the Dispensers tab on their old Freewallet to buy some XCP or another asset, not checking live explorer and sending funds that won’t carry the correct prefix to trigger that dispenser any more?

They won’t see a warning in their freewallet as it will be an old version.

But who would buy from a dispenser without checking it live on chain, someone who is not careful.

A bigger personal concern is the removal of layering of assets at multiple price points to be triggered by a single payment >= a set of dispensers on a single address.

People have been using that feature to do multiple asset vending sales strategies.

> A bigger personal concern is the removal of layering of assets at multiple price points to be triggered by a single payment >= a set of dispensers on a single address.

Sorry can you elaborate on this?

> They won’t see a warning in their freewallet as it will be an old version.

afaik they'd still see the "update FW" message that FW has.

Pay 0.01 get X, Pay 0.1 get X + Y, Pay 1.0 get X + Y + Z

This is done by setting up a dispenser for Z at 1.0, Y at 0.1 and X at 0.01 all at the same address.

I've encountered a lot of users that rely on FW mobile, since it's really the only option

Yeah so that would be much better with the new version. You'd be able to specify exactly which asset you'd like to buy at any given time.

I have used it for dispensers too

Would you be able to get all 3 in one tx?

that's just triggering multiple dispenses, yes?

I mean we *could* do that. It'd be ugly :/

@teysol it's already supported

yeah but in a weird backwards way

Am I crazy? Why you think this is not possible?

https://www.xcp.dev/address/1CjvK8mWYZd8tJ2vbN8G8jNC23U2fzgUCf

like you can only buy more expensive assets if you also buy the cheaper ones

I get the reasoning to add the prefix.... The pros probably do outweigh the cons (if wallets implement smoothly and all wallet devs remove "old" version functionality by force to upgrade)...

If all those devs somehow implement a user to forcibly upgrade, the fallout of bad dispenses will probably happen with some nonxcp wallet that somebody still uses... minimizable, but unavoidable...

But there is some art to CIP-21 that will be lost... and it will take a while for some users to transition (the ones that dont always dispense with xcp wallets... Yes, Xcer they exist)

And the bashing of CIPs and the process that has been used for years near the same time as well... Doesn't sit well with someone who loved to research and dive into all the CIPs accepted or not... Especially since PSBT support and Atomic swaps were presented in that manner

That’s right! It’s me.

Yes, that current effect has been used deliberately by some artists to allow bulk purchases of a range of issuances and rarities at different price points

Is part of the design of address pages in xcp.dev

This sounds simple.

CIP 21 is underspecified. That's not "bashing". Dispenses broke Counterparty's tx model and the specification for the feature didn't say it would. Again, it's not bashing to call that a bug.

Bashing CIPs in general...

Or even the idea to present this as its own CIP

The CIP process isn't an improvement proposal process. The process itself as detailed in CIP 1 hasn't even been accepted.

Everyone uses a wallet to buy from dispensers. It is a write, not a read.

Counterparty is Bitcoin.

I am in Bitcoin’s token layer. Created by you. Thank you, and it is amazing. And flawed. And that’s ok. Lets move forward where we agree, which is A LOT!

No need to push any controversial upgrade.

The "need" has been laid out countless times today. You can acknowledge it or not but at this point it's bad faith to say that it hasn't been explained.

Counterparty isn't Bitcoin. If it were this entire discussion would be needless.

I’m sorry Juan, love you mate, but this doesn’t make sense, doesn’t advance the conversation here.

There is a clear need to fix a performance bottleneck, that is what we ought to focus on?

I buy from dispensers with the create send function, with BTC as the asset. Using a Counterparty wallet.

the CIP process is highly respected.... and CIP-1 is shown as Status: Accepted

status active on the main cip page

active isn't accepted

Cip-1 is an explanation of how to present a CIP to the community....

beside the point: if it were canonical then dispensers never should have been activated since the CIP is still "Active". And even if it were "Accepted", breaking Counterpary's transaction model without explicitly saying you're going to do so constitutes a bug.

This isn't "bashing" it's simply asking you to accept the logic of your own argument.

Do you run a node?

I run. More than 1. Which I pay every month.

Development cannot be hindered by a parsing speed optimization.

The top used “Buy TOKEN(s)” use case is being broken (a backward INcompatible change).

Is really that simple.

"It's really that simple" with the caveat that of course it isn't that simple at all. If you want to trigger a dispense (i.e. a Counterparty tx) you need to use a Counterparty wallet. That's the change.

addresses themselves won't have a problem right? it will be just about writting the new proper cp tx, right?

yes, you just need to use a(n upgraded) counterparty wallet.

I’ve been in CP a very long time and development has never been so active.

We were smashed by ordinals by a magnitude of 10,000X

If we want to keep riding a horse and buggy into oblivion, let’s keep making it really hard for our devs to make the protocol changes they need necessary.

Soon we won’t have any developers at all.

Not just any developers, our literal founders

You mention XCP.dev but it doesn’t have a skin anyone in the community can use besides rocket scientists like yourself

For now.

I think everyone can agree that the current v10 optimizations have been great. We all upgraded (still not to production though).

But these updates don’t have to be perfect. We can continue solving the tradeoffs from the agreed releases.

I am VERY grateful for the improved software. But this is not a free pass for ANYTHING. Then, we are not decentralized.

Let’s focus on (even) more optimization later. Truly, it has been more that enough already ❤️🤓.

Why are we horse trading here? Atomic swaps will hit performance hard. Adam wants to make performance as good as practicable before that (for pretty obvious reasons). And it will simplify consensus-critical code (which, for the millionth time, has been the source of most consensus issues). What event will trigger the acceptability of doing more performance optimization?

The argument seems to boil down to "why NOW". Why not now? An enormous amount has been fixed without any protocol changes. We've reached some theoretical limits and now we need one. "It's as simple as that".

This only affects parsing time. And there is a general floor (limit) time on parsing, the Bitcoin sync itself.

And people using bootstrap have not much benefit. Which have been the majority of node runners in the past.

And with UTXO binding, now these become “a bitcoin transaction” to be tracked block by block. Not the same, but it is a growing number.

On the contrary, each block has a ceiling (limit) of transactions.

And the “main current competitor” to Counterparty, ord, doesn’t only Checks all transactions… it Tracks ALL sat ranges from all UTXOs from all transactions!

Reading (maybe writing), each bitcoin transaction is not really a big deal.

AND, with this, the burns csv can be… 🔥

I will review the GitHub discussion across the weekend and add whatever input I can see is useful.

@uanbtc you're constantly beating the drum about decentralization and claiming tyranny whenever someone makes a decision you disagree with. If you truly care about decentralization you should want syncing to be as fast as possible.

The plan in the github issue (1670 😆) was to add a CSV similar to the burns.

So unsexy

Only once

... unless you need to reparse or your computer breaks or etc.

Or, since one of the main concerns seems to be that a user goes away for a while and isn't aware of changes to the software, what if I turn on my node after a year and need to catch up?

People buying from dispensers using a BTC send. No other steps.

Unless they use a taproot or p2wsh address in which case there's one more step: saying, "where'd my money go?"

This is a feature, not a bug. IMO.

i don't see it in CIP 21

Is more like: included for free.

speaking of people losing funds, what if I as the seller didn't mean to include things for free?

The bottleneck argument is nuanced.

I think I have already explained it, but can repeat (still getting up to date on the messages)…

Finally. Not feeling like repeating myself though. Was going to add more replies but it was just repeating what has already been said.

To conclude (from my part) on a hopefully positive note, let’s bring back the CIPs repo (and discussions).

Weird not realizing how bad of a look that is (especially today). Without any discussion or warning (that I know of).

I believe discussions, and disagreements, make a stronger decentralized network.

Sometimes it seems like you are arguing for the sake of your own belief that it means decentralization

It's getting hot in here 😅

We have an infiltrated here

You cant require/enforce users to only hold tokens in 'counterparty' wallets ..

No one mentions how every p2pkh address has to be checked as p2pkh encoding does not use op_return

simply holding a token and signing a text message with the private key is using counterparty

ah, p2pkh, often overlooked, that's a good point from B0B

you may not be issuing assets, buying from dispensers even you could have been gifted a counterparty token on a opendime

what operations are performed this way?

yes, there are examples of this, people have sent Counterparty assets to opendimes embedded in physical artifacts

signing into that music site I can't recall the name of .. it allows you to access music tracks if you hold tokens

ah, like the first ever token gated music album, DJPEPE 2016 by Scrilla, on Soundcloud

not sure if Adam Levine did anything like that with MTM tokens as well or not

I like the idea of token gated access or token plus a signature as a access method

yes, I'm looking at that for some subscription services I have planned for later this year

so goodbye p2pkh encoding too ?

I don't know about that, something we'll have to wait for @teysol to consider and respond to

tokens as memberships for subscription services are a great idea and end user never needs to touch counterparty transactions

they can be a passive end user

we could have users who don't even know counterparty exists

yes, they can just provide a BTC address when making any kind of payment, BTC, LN, fiat, and then subscription service provider can then send the tokens to the nominated address that's registered with their account

I'm looking at doing this for monthly coffee subscriptions

COFFEEPARTY.1KG202407
COFFEEPARTY.1KG202408
COFFEEPARTY.1KG202409
COFFEEPARTY.500G202407
COFFEEPARTY.500G202408

etc

you could even dividend air dop new tokens to existing unaware users too to save on (multi)send fees

sure you pay some xcp but only 1 small opreturn btc tx needed to distribute lots of tokens

we've had various artists issue additional ongoing artworks to their primary OG art tokens that way, including a bunch of DJPEPE subassets from Scrilla, as well as Boost's 16 VAPORMAGIC sub-assets

As the apiv1 unpack() command was soo limited in its scope I looked at CNTRPRTY messaging n found the p2pkh method .. so counterparty is already checking every p2pkh address for messages

p2pkh encoding makes op return censorship pointless

I been using Coinb.in and Op return as electrum is not flexible enough 😂

what other counterparty wallet has OP_HODL ?

the issue is not that *something* happens for every UTXO, but that there's a db call (to check for open dispensers) which makes it impossible to pipeline the parsing

that makes sense

as long as opendimes remain valid counterparty wallets

you can't stop ppl using coinb.in

all you can do is censor address types

agreed. this discussion is not about holding tokens but largely about whether buying tokens from dispensers in vanilla bitcoin wallets is a feature or a bug

reasons it's not a feature:

1) you can't just use a vanilla btc wallet... you also have to use an explorer to find the open dispensers

2) the whole reason it's even desirable is that existing counterparty wallets are very bad (or just focused v much on NFTs or something). the only mobile wallet hasn't been update in *five years*.

3) using a vanilla bitcoin wallet is inherently unsafe, and currently the cause of loss of funds, as is demonstrated by the big red warning banner on the xchain dispenser page

reasons it's a bug:

1) multiple dispensers at one address is shitty and causes loss of funds

2) the current implementation is a *major* source of performance problems and code complexity

3) it was not part of the original feature specification

The CNTRPRTY prefix is what makes a message Counterparty .. be it in p2pkh p2ms op_return p2sh .. its not where it is but the fact it is

we have been using counterparty without the prefix I know .. we all guilty of that

could existing dispensers be grandfathered to work with no prefix but new ones require it ?

yes but I don't think that will help. the dispensers don't have to change. just the dispenses do

if they prefixed can dispenses become larger than 1000 again?

as I understand it the 1000 limit was antispam .. but if msg includes cntrprty prefix you can't say its spam

I don't think any counterparty txs are spam personally. I imagine it was a performance issue.

not sure if this'll address that. that kind of issue is probably only really solvable with a gas system but I don't want to speak out of turn.

without the prefix could be argued is spam

i mean it's an attack vector right?

its at least out of scope

you could halt the system without the limit

anyway will get back to you! thank you for thinking of it 🙂

yeah it's independent. dunno what the 1000-token limit was put in there for... I don't see how that could be helpful for SPAM

Probably nothing that hasn't been said already but trying to see the trade-offs I am wondering if the "send btc to this address to get the asset" for non counterparty users is really a desirable case (and if with current counterparty activity something we should be really worrying about tbh), distributing assets to users who don't have a counterparty wallet feels pretty much like a dead end for that counterparty journey

Current dispensers / users entry point is through explorers (mostly xchain now) that could serve the same warning as we have now for empty/closed dispensers or taproot addresses, or wallets like the freewallet dispensers tab or ninja wallet built-in purchase. So feels like the loss of funds prevention is being made already in terms of tools' UI and not much is changing there as it's already being abstracted or guided for the users

I feel the nostalgy of how dispensers work and what we are used to, but also remembering how we've been trying to figure out how to improve or prevent risks, it feels like going to a counterparty transaction is a start

ppl put dispensers on exchange addresses that were distributing many token to mostly unaware users

wait... were they were creating dispensers on addresses they don't own?

the exchange did not setup the dispensers and the users were unaware ..so

yes and busy addresses with lots of txs

oh my god

I didn't know that was possible. That's terrible.

I'm pretty sure dispensers have been opened on Satoshi's addresses

you absolutely should not be able to open dispensers on addresses you don't own!

Ordipepe

okay, I take it back. it's totally not independent. we could remove the 1000-token limit trivially with the proposed change

that is what was causing all the spam token distributions, some clever clogs were opening them on exchange hot wallets to spam their tokens to the world

What were the others?

Ordipepe had over 20,000 dispenses

Forgot this 😁

they won that game

yes, in general, this proposal would completely eliminate *all* accidental dispenses

(because it would make dispense a Counterparty transaction.)

yeah the 1000-token limit was added just *last September* in a mandatory protocol change, and that's obviously a hacky patch over the fundamental problem which does need to be addressed. accidental dispenses are a real problem

At one point nearly all the "dispenses" on Xchain were pages and pages of spam tokens that had been opened up on non-xcp exchange addresses and "bought" by users. I'm not sure how they're being filtered currently

@teysol would the issue where you can buy from an empty dispenser be eliminated by adding the prefix?

If PSBT is coming, why are we so concerned about dispensers? Am I missing something that dispensers are able to do that PSBT wouldn’t be able to do?

Dispensers still a good way of selling multiples by setting up a single txn. Not sure if PSBT can offer something comparable

For 1:1 assets PSBT seems superior

Is there a way to fix Dispensers, or are they just inherently broken? Unless they can be made unruggable, they should certainly be removed once PSBT/Atomic Swaps are implemented and used.

adding new features is usually not the best way to fix bugs in existing functionality :/

Inherently broken.

Yeah, the design of dispensers is fundamentally flawed. :/ There's no way to prevent rugging in general. This proposal is to fix the _implementation_ of that problematic design, and it should be pretty uncontroversial for that reason.

It's going to be a *while* before atomic swaps + fancy wallet features are able to replicate the full functionality of dispensers, which are indeed extremely convenient to use.

People (or at least I) buy from dispensers using a send with BTC as the asset. Using a Counterparty wallet.

Not sure why it keeps getting repeated that this is about non-Counterparty wallets… Even though I think we should embrace non-Counterparty wallets to interact with the Counterparty realm. IMO.

With the introduction of binding assets to UTXOs, the most optimal parsing route will be checking all transactions per block. Why?:

These CANNOT be more than 10000 (few blocks have gone above this number). There is a ceiling.

So, after Counterparty has more than 10000 UTXO bound balances, and this number DOES continue to grow (there is NO ceiling), the most optimal parsing strategy is checking each transaction per block. Not each UTXO from the Counterparty DB per block.

Or am I wrong in this analysis?

This has already been mentioned but wanted to make that point very clear.

I mean yeah, the node software will be able to do a simple sanity check to make sure that the dispenser is open when you try to trigger it. using vanilla BTC wallets to trigger dispensers is fundamentally unsafe and can lead to loss of funds in multiple ways—this proposal is what the fix looks like

so to be clear, this eliminates another potential avenue for loss of funds

so basically aside from inherent limitations in dispensers (rugging etc.) by adding the prefix we'll be able to address the various ways buyers *and* sellers lose funds... unless the buyer isn't using Counterparty software to make a Counterparty transaction.

Just kind of thinking through the current UX of xchain (which isn't interchangeable with everything Counterparty, but I digress)

Right now, the QR code presented is just an encoding of the actual receive address without a URI. Typically, sites that present a Bitcoin address will preface it with a bitcoin:// URI to prompt the OS to open an associated application (typically a Bitcoin wallet).

Perhaps, going forward, explorers can use the counterparty:// URI so that in instances where both a vanilla Bitcoin wallet and a Counterparty wallet are installed on the OS, the appropriate wallet will be opened. Could even be: dispenser:// so that the wallet is already in the right "mode" for sending to a dispenser rather than a vanilla Bitcoin transaction (which is also a common usecase of a Counterparty wallet).

Just bringing this up, as I think some best practices are in order to ensure the ecosystem is guided down a predictable path in terms of UX.

Best practices are great and this would be great to see but really simply you could remove the banners not to send from taproot or to send BTC to an empty dispenser and just have a new banner that says: "Use a Counterparty wallet to buy from this dispenser". Such warnings are an established workflow and this one isn't qualitatively different from others.

This is true. But users don't read (their fault) but it can cause headaches. They often stumble into this chat asking what went wrong. A custom URI is an additional preventative step. Right now when I scan that QR code with my phone, it says "Search the web for..." which is terrible. I have to then copy/paste the address string and manually paste it into my wallet.

Oh sure I am just talking about parity with the existing dispenser workflow. improvements would be awesome but the concern at this point is that people will lose funds and I am pointing out that 1. the change will moot the existing warnings; and 2. a new warning can be put in place.

Would also be good if the "use a counterparty wallet" message was actually present somewhere close to the QR code with a link to some actual compatible wallets.

One more idea (just spit balling here), but what if explorers didn't present receive addresses at all. Instead you'd have the QR code with URI (to prevent sends from vanilla Bitcoin wallets) as well as a "redirect" URL in place of presenting the bare receive address. Something like: dispenser.io/xiPtrZ

This address would redirect to dispenser://receive_address

The idea here is to try and prevent users of vanilla Bitcoin wallets from sending to dispensers, post-upgrade.

Counterparty-compatible wallets will understand the dispenser:// URI and proceed.

Counterparty balances are public. To check my balances, I can just check the address in any explorer.

I find it a cool feature, not a bug, that I can buy Counterparty assets from a non-Counterparty wallet.

I can understand this provides no validation of course, as it is not interacting with the counterparty-core to create the transaction.

(And I assume the majority of users don’t do this, they use a Counterparty wallet. Like I do.)

And if we really don’t want normal BTC transactions to be Counterparty transactions, then UTXO bound assets should be a no go.

I’m just weirded out by why the insistence on breaking the most used way to buy assets: from a Counterparty wallet, select BTC asset, and sending an amount to an address. It couldn't be simpler.

I find it completely unnecessary for a performance gain that only VERY few (node runners that don't use bootstrap) will even notice.

The main place that performance affects users is in the follow, an up-to-tip node that is parsing new blocks. Here, the balances of the complete ledger should be verified! The current v10, skips it (is not doing the check at all).

I want to see how the profiling (performance test) looks like with asset conservation. I anticipate this will make the “is dispensable” check irrelevant in comparison.

If im wrong in any of my thoughts / analysis, please let me know.

A few different things:
- First, I understand that you think it's cool that you can trigger a dispense of Counterparty assets without a Counterparty wallet. Its coolness is not in question.
- Dispensers are *underspecified*: the fact that we can disagree about what's a bug and what's a feature of dispensers is the entire problem; if dispensers had been fully specified there would no debate. However, if some behavior is emergent only because the fundamental abstraction boundary between Counterparty and Bitcoin was unintentionally broken then it has to be treated like a bug.
- Dispenses can work without breaking the abstraction boundary between Counterparty and Bitcoin; UTXO binding is a means to an end for trustless atomic swaps and in that case breaking the abstraction boundary is a feature requirement and will be done so *carefully* and intentionally and the performance considerations will be part of the design process.
- We will eliminate several paths to losing funds and probably be able to remove the hard-coded 1000 max dispense by introing the prefix into dispenses.
- If you care about decentralization the FIRST thing you should care about is node performance.

Finally, it seems obvious to me that if the people responsible for all of the massive performance improvements over the last few months are saying that performance is still a concern then that should be taken seriously...

Hello. I used "counterwallet .io" previously but now it's not working anymore. what are my options to recover my XCPs? is "freewallet .io" trustable?

I feel like my message is not getting across. Or parts of it are getting ignored.

But I do appreciate the conversation is allowed.

Let the readers decide. I’ve already done enough explanation.

Increasing the friction by requiring a counterparty wallet to buy from dispensers is a tough sell .. it is very cool that it hasn't been needed thus far and it would be nice if it could continue

I not sold on the idea the idea the prefix solves user funds loss issues .. it may be able to be used by counterparty core to stop it from generating tx hex to closed dispensers but if the dispenser is open then counterparty core will always allow you to buy  .. but as to whose tx is mined first will come down to a fees race condition as it currently does

the only reason that it has been possible is that there is no prefix.

you just said this earlier today

even with prefix as dispenser opens up to sell 1 card .. 10 ppl hit the nodes n generate tx hex to buy .. all txs are mined but only 1 person gets the dispense

yes, in the same block

could be over many blocks depending on user fee

that's just how dispensers work. otoh sending btc to a dispenser that has been emptied in a block before you construct your tx is still an issue today.

yes that is true but a prefix has a very limited scope to protect users from a dispenser fee race condition

But these are just downstream benefits of adding the prefix. Do you not still agree with what you wrote earlier today

it is one benefit of but not the motivation for adding the prefix.

I am just pointing out it won't solve all the money loss issues of dispensers

the prefix is what defines counterparty to a large extent but not fully, due to the fact we have dispensers currently working without it

... again, with all sorts of negative consequences. These arguments have been hashed and rehashed. Not having a prefix is a solution that is too simple for the problem it's solving: interoperating with BTC. The correct solution is utxo binding.

I like the prefix .. I had my own op_return prefix project in 2014 .. a shared prefix is a cool idea

Not everyone uses Counterparty core to generate their op return (tx hex) and adding a prefix doesn't change that .. so you could still see transactions for closed dispensers

I looking at using counterparty to make my op return so I can extract it and build my tx hex elsewhere to use with p2sh

Since no admins seem to be online. which wallet do you guys use atm?

I don't know what to say. The tradeoff is well understood: you will have to make a Counterparty transaction to make a Counterparty transaction. It is understood that this will affect some users but the reasons for the proposed change have been laid out in great detail many times.

freewallet.io / rarepepewallet.wtf

The change is clearly a good one

Which, for node runners that want to “don’t trust, verify”, will always have to detect.

So breaking the most used way to buy is “clearly good”?

Is an unnecessary optimization. The kickstart, as it exists today, already lowers the parsing time from weeks to hours!

Let’s add alternatives, then if something better comes up, users will move. Then, deprecate.

>So breaking the most used way to buy is “clearly good”?

source?

You're saying the *most used way to buy* Counterparty assets is with a Bitcoin wallet?

How are you judging whether the the work is necessary?

I have one more question about the proposed update.

does existing dispensers will have to close manually?

if so what will happen to current innactive users that have many open dispensers?

this doesn't affect dispensers

only dispenses

From Freewallet:

Select BTC, send.

Enter destination address.

Enter amount.

Send.

(Block mined.)

See new ASSET in wallet.