got it, thx

there is one change: if you want to trigger a dispense you have to do so from a Counterparty wallet.

... that workflow will remain the same. Good grief!

Or rather, it will be select dispenser, not select address (which it shouldn't because dispensers aren't addresses...)

Evan don't feed the trolls ;) nothing that @uanbtc is saying makes any sense

If dispenser purchases without a prefix are problematic, then it needs addressing, adding friction to asset acquisition is a tough call but if its the right fix then we should be open to it

The 1000 dispense limit was the solution but it seems its not the correct fix and it seems the 1000 limit can even be removed with the addition of a prefix

Users have been known to buy from dispensers using exchange owned addresses and the prefix stops that mistake too 

Nothing. Ok leader.

@uanbtc the workflow you described will be essentially the same. Can you actually engage with that rather than redirecting?

Thank you AI

Ok let’s engage. What is your workflow?

First question. There is a selection of a dispenser. Is it the txid or the address?

it's the dispenser ID.

Dispensers aren't addresses.

Already right there is not the same workflow.

To users, they are

Assets available at addresses

so you can search dispensers by address... this isn't a super hard problem to solve.

Average flow has been people ending up in xchain and copy a string to paste in freewallet, the concept of address in there doesn't matter that much to people imo, they copy paste a string and forget about it

and that's a wallet flow, same flow could have been done with the ID

The address abstraction allows for multiple dispensers in a single address.

there is an api method for this for pete's sake.

100%, the prefix forces users to use a counterparty aware wallet, something they should always be doing when interacting with counterparty

Always? Don’t agree but I get the point.

This was simply an oversight when dispensers were deployed, there was no discussion of “should we add an opreturn to dispenses” it just wasn’t considered

We’ve had a lot of discussions over the last year+ about things the degrade counterparty node operation, this is actually one of those things where we can make a change that allows node software to easily recognize all counterparty txs without having to assume every single btc tx might be a dispense

Are we sure it was an oversight? Wasn’t the design to allow normal BTC tokens buy Counterparty tokens?

Thus the name, dispenser?

And it forces users to dispense from a counterparty wallet so no accidental sends from regular Bitcoin wallets or exchange addresses

100%, the goal was to eliminate the 2nd Tx of the btcpay

swap bots were a thing too

So dispensers became a sort of bastardized btcpay that come with all sorts of tradeoffs but at the time we considered those tradeoffs worth it

But the idea of adding an opreturn to indicate a dispense as a counterparty Tx was just not considered at all, I think if it was we would have done it

And have been a hit! We must be careful with breaking changes.

What will the cntrprty mesage specify?

I don’t disagree, but we’re not talking about getting rid of dispensers, we’re talking about requiring an opreturn to force users to send to dispensers from counterparty wallets

It encourages behavior that we want

It encourages onboarding to counterparty (which is reasonable to expect it from people that interacts/collects with/in the protocol)

“I sent to a dispenser from my trezor, now what do I do”

I’ve heard this more than once

Replace trezor with any other non counterparty wallet

tokenly swapbots repo has cobwebs due to dispensers

This is a separate discussion imo

We should be discouraging importing private keys from other wallets into counterparty wallets

It just creates more confusion

Then people reset their wallet and wonder why their passphrase isn’t making all their imported addresses appear

fair enough but before dispensers they were the easy on-board to getting assets

I disagree. But that is fine, I still use a CP wallet for BTC sends to dispensers.

What really would help is adding a cntrprty message to the BTC send.

Still, a breaking change though. So it must be very carefully deployed.

In my view, the “benefit” (VERY few users (node runners without bootstrap)) is not worth the trade off.

And the code will still be needed to “dont trust, verify” forever.

Sure, why aren’t you running any?

Disagree

The goal is to get more people to run nodes!

The answer is because you become a custodian

No one wants that generally lol

Which is why dispensers were the tradeoff

Dispenses are the only counterparty txs that aren’t labeled as such

A feature, not a bug, IMO

I agree with statement that they are a bug

What will be specified in the mesage?

there is an open issue for this, Juan.

True. Enough here I can agree to that

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

you don't agree that the absence of a prefix is a bug. that's weird but whatever. if you're interested in the implementation you can check out the github issue. if you want to relitigate why the change is important you can read this post: https://github.com/CounterpartyXCP/counterparty-core/issues/1670#issue-2243918759 or read one of the many articulations of the same in this chat.

"We could also block creating dispense transactions when there's already one in the mempool."

whose mempool?

what size mempool ?

please engage with github issues on github :-/

You can't create a risk free environment .. it makes
sense for advanced users to use pure hex in op return and not need counterparty api to create tx hex from a speed perspective

This was fixed. You *can't* open a dispenser on address with ANY BTC tx history.

that is a weird fix.

but good to know!

I disagree. I've helped people open a dispenser on their address from my Source address. It's really really helpful

There are plenty of things I don't know, and I do my best to ask questions in those cases.

so do i

Pepe always has an open call enabled to resolve doubts; simply enter kek-kek-kek on your device.

https://pepe.wtf/asset/GOOGLEMEET

Toxic. He has made very clear points

First 10 addys

1E6tyJ2zCyX74XgEK8t9iNMjxjNVLCGR1u

14VhF5JGExMn4qkN2RiMqNvCwpqmFvbQaz

1AB754RdrxVNeYXESKACXvjeJqT2LPhU8N

This is also true

Agreed.

1Mq8jAW43ULNgmq4esDZaNGTZasBC56ooz 🙏

1NnLKuMR1h78pU7wDh7fhWoo1X33a3EQWQ

1ITSANASK4ADDYTR011

First batch on the way 🤝

1PU8Ymb6G9XG4gGt2PYGVTHrJFzub2bHJ8

197MZh186ZWCrad3quyDTZ8Fm3HS5rhR9r

Despite the maintainer shitting on opinions he doesn't like, saying "nothing an individual says makes sense" when they are making clear sense of their position... I like that the discussion is FLOURISHING from me bringing up the possibility in question... It's really really awesome to see the whole community getting their opinion heard..... And if you want my 2 SATs...

My question is still: Why right now and not later? Especially when future updates will make it so dispenser are less used in the future! It's a good upgrade to dispensers...but HOW you release this and in the best way possible for users is the question

Future applications won't replace dispensers for non-Counterparty users

that's the whole point: by breaking Counterparty's tx model non-Counterparty users use Counterparty

So let's turn it around: why later and not now?

Is a breaking change

it will be a breaking change later

by every metric more work has been done in the last 4 months than had been done in the preceding 8 years, all without a breaking change

The reasons for the change have been laid out ad nauseum.

Someone was kind enough to setup a dispenser on a address of mine, I think being able to open a dispenser on any empty address is a cool feature ... no one can prove they own a burn address and they are used by 'fair' mints was it xcp20 that used burn address dispensers

Maybe is better to break something that has already been replaced with something better.

Not break the main use case to get assets.

Is so basic man. But engineers over-engineer sometimes. And can’t see the user’s side.

I am aware of this phenomenon and am trying to protect Counterparty from it. Because I like dispensers and don’t have something better.

What has been your experience with dispenses, as a user? Asking the retuning founders and “core devs”…

you're moving the goalposts. you said, do it later. i asked why.

No replacement.

you can't replace the use-case of using non-counterparty software to make a counterparty tx

For the 10th time, I don’t lol

then i don't know what you are talking about

that is the only thing that is changing.

The workflow is going to change from a simple BTC send, to a “create dispense” that will create a CNTRPRTY message that I haven’t been told what will include…

Well, because the current version of dispensers don’t require anything! So, is the message really needed?

The plain evident obvious truth answer: NO.

Can it be over-engineered and broken for a minor gain in optimization, sure. I don’t think this is worth it (al least right now).

I’m done (for now). Too much repetition lol

It’s not over engineered it’s simply engineered in the absence of engineering

Ehh no. It works today.

And dispensers will continue to work

And nodes will be faster

It is something different, but using the same name.

For very few use cases, and maybe negligible for synced nodes

Use cases?

Node runners that don’t do bootstrap

This is to bring dispenses into the same structure every other counterparty Tx adheres to

That’s the goal

No bootstrap

More nodes

Ok yeah. Not debating that. The GIANT gain in performance has already happened. Then next improvements are negligible in comparison to how it used to be

Source?

Im done lol.

The performance problems cannot be really solved with the existing is_dispensible call. parsing time will continue to grow in the number of bitcoin transactions.

there will be no replacement for triggering dispenses from non-CP wallets (which is the only thing that's changing)... by design. So why should this change be put off?

xcp20.wtf

This was a joke btw

Oh, and we need a breaking change to remove the addrindexrs dependency anyway.

Was it tho? The Bitcoin was certainly real 😁

Sometimes jokes are expensive

We laughed... they cried... haha

They got what they paid for!

Proud holder of 1%

proving you own a address on which to open a dispenser gonna make for bigger dispenser opening tx,

can you fit the dispenser opening data along with a signature in a op return?

Why would you ever put a signature in an opreturn

i wondering how to prove addresses ownership, without a signature its nigh impossible

I imagined that it'd be reasonable to require the dispenser to be the source address. If there's a problem with that I'd be curious to hear it.

we recently have option to open and even refill dispensers on non source addresses

empty as in no btc tx history was then added as a requirement

lol wait, I figured it out. you wouldn't be able to receive any BTC without triggering an accidental dispense 😂😂😂

ugh, the current implementation breaks so many things

I've never seen a bigger footgun in software. and every single bug is now somehow supposed to be a magical feature lol

It’s years of trying to fix all the unanticipated downsides of the implementation while still keeping the desired functionality of being able to buy assets direct with btc in a single Tx

Has anyone here NOT accidentally triggered their own dispenser?

I’ve personally lost $1,000’s.

I would also prefer not to have 50 different addresses with a dispenser on each.

If I trigger my own dispensers, imagine what must happen to a newb.

Every time a new user joins CP, you have to explain, to not send your own BTC to your wallet if a dispenser is open or you may lose your assets…

Or what about newbs setting up 5 dispensers on the same address thinking each would trigger individually but ends up losing all their assets in a single dispense.

Seen it happen many times.

All while the parsing debt continues to grow daily.

So were wanting to make all these trade offs just for a few users to be able to buy assets but never be able to do anything with them lol

Dispensers are impossible to explain to new people, I always recommend avoiding them because of all the pitfalls

And to only use them if they’re 100% sure they understand the risks

not everyone got what they paid for, doubly expensive joke for some

when managing creation of a set of dispensers, I will generate my asset tracking sheet, allocating them to addresses I control (list of PKs)
create them sequentially from a single address that I control, targeting each public address in turn as I create them
this way I'm not having to manually switch addresses for each dispenser I'm creating and I'm not having to send all the assets to each address first either
and I only need to have enough BTC in the address where I hold all my inventory
the target addresses don't require small amounts of BTC sent to them first either

I sent out a sub-asset called FLOOSER to all the losers.

I must have about 200 dispensers open currently, not having to manage them at different addresses would have made my life quite better

well, that's FLAIR

sure, if they are all going to be discreetly manageable under our single origin address, which seems to be the suggestion?

which breaks the unintended multiple dispensers cornucopia layering distribution "feature" that some have taken advantage of

NGL I've had fun with that 🤝

My management is searching xchain history lol

I'm not sure yet what happens with those existing dispensers once the proposed changes roll out... they won't all dispense simultaneously anymore?

will the owner of them need to close them all?

most importantly, will they be able to close them all?

I didn't realize how bad the accidental triggering of dispensers was... am shocked that so many people here are just okay with it being trivial to cause users to lose funds like this. all in the name of some fantasy that it's secretly bringing in non-user users, or because they have some bizarre notion that "Counterparty is just Bitcoin"

the proposed change would (if I'm not mistaken) not require any change on the dispenser side

I am uncertain about the proposition for having a discrete selection method for each dispenser on an address, rather than specifying an address

is that currently at the ideas for discussion stage, a future suggestion, not bound into the current proposed cntrprty prefix requirement?

sorry if that's already been clarified, I haven't had a chance go back and build a clear mental model of the last couple days of discussion yet

What’s the concern?

dispensers aren't addresses so at a protocol level they shouldn't be equivalent. on the frontend of course you can break that abstraction boundary.

if there are things that can be done at the protocol level to protect people from unintended loss without impacting performance and breaking existing widespread usage practices, I'm all in favour

re. Juan's concern, I am not aware of there being widespread practice of people triggering dispensers from non Counterparty wallets, I was not even aware of anyone doing this intentionally prior to the point being raised

These are mostly imaginary users I’ve concluded lol

Just the rocket scientists do it. Idiots like me don’t.

I have two right now from a non-technical users perspective

1. layering of multiple price point dispensers on a single address as an intentional sales/distribution strategy
2. ability to deploy dispensers to other addresses I control from a single address with all my inventory and BTC for fees

changing 2. is not part of this AFAIK. 1. would indeed not be automatic but can be done at the application layer.

it's very helpful to know what existing workflows are since dispensers' behavior isn't specified and is genuinely surprising in some cases. thank you for talking it through

I have to say that (1) sounds less like a feature and more like a way to steal someone's dispensed assets. It'd be good if the dispensing address had to say explicitly that it wanted that to happen.

adding my third point, will there be any future issues in closing multiple dispensers set up on a single address

as a matter of current practicality, with freewallet being the only utility currently in use by the non-technical user base, this is most likely a question for JDog re. the freewallet dispenser close function

dispenser close shouldn't be affected by this.

2) is about me creating dispensers from my inventory address onto a set of other addresses that I control, so they are able to be separately catalogued, tracked, managed

I represent some artists as their dealer/broker under long term arrangements where I manage their inventory from a single PK

in terms of pricing and market strategies, it's very important to be able to create different price points and quantities of their assets on different addresses

sorry I meant (1)

I then periodically sweep the proceeds of sales back to their consignment address

they absolutely got what they paid for, they got the result of not paying enough in fees

okay, (1) yes I guess some people might be unaware that they're risking the dispense of lower priced assets simultaneous to higher priced ones, but I think there's only been a couple of instances of that happening

anyone thinking it through logically, or reading this and other groups, ought to understand that is what will happen

an exercise in experiential learning

Yep I made a mistake. dispensing all assets below a price point will indeed no longer be enforced at the protocol level, however it could be orchestrated at the application level and it seems important that that be the case, otherwise any address with multiple dispensers can get its assets stolen...

Random dispensing would be INCREDIBLE

Put 100 assets in a single dispenser and it randomly dispenses 1

lol, that could be an application thing if people wanted

It would be huge

I point to the Rare Socks example again, as a collection where this current behaviour is explicitly the chosen sales and distribution method of the artist / collection creator

sure! you can still do it at the application level but this is implicit behavior enforced by the protocol ATM.

And someone who doesn't know that and who sets up multiple dispensers at the same address risks loss of funds.

Who’s putting a 1,000,000 pepecash and 1 Naka in a dispenser for a dispense price of $1

lol that would require a protocol change and the conclusion from the last two days of discussions is absolutely not that people want changes to the protocol.

if we think protocol changes at 10 years are hard, imagine them at 20

I think the NOs just get more attention. I think the vast majority want the protocol to evolve so we can grow.

CounterBerry

bro

wth

I leave for a day and you have fun without me.

Consider this perspective: The core developers' desire for change carries significant weight. These individuals volunteer their time and expertise to enhance Counterparty. While you might not be fully convinced about a specific idea, it's important to factor in the satisfaction of the core developers in your evaluation, as their continued involvement is crucial for the project's advancement.

with all that has been written here, if we transform that text into code, we would have solved all the bugs....

https://github.com/blocklack/counterparty

a bounty to build a NPM package, if you are interested just pin me

to be fair, cp is very idiosyncratic anyways. kinda why it doesn't have had enough adoption broadly, imho, as it requires some effort to get to understand its mechanics.

we love it of course, though, but for normies it is still kinda hard to grasp in comparison to other ecosystems.

RPW is stupid simple

@hodlencoinfield is there a specific reason why dispensers are not included?

I think Joe said above he doesn’t even recommend dispensers because too many things can go wrong

yes because i fear people will blame me if they lose money on them

i was also waiting for the ability to close dispensers from origin address which helps a lot from a UI perspective but in the meantime ive come to realize that dispensers function more as a stop gap measure until something better came along, and that something better is psbt atomic swaps

yep, but we also have a lot of incentives NOT to do that

Deleted, no reason to give ideas

hahaha which is an indication of just how distruptive they are

cant even talk about them for fear of giving away attack vectors

This has caused the loss of so much more money than whatever the fix will cause

The multiple dispenses from and single address is a commonly used feature. And is not too complicated to understand its behavior.

@rarepepetrader you are clear that the proposed change, is mainly that the dispense won’t work from a BTC send, even if done from a Counterparty wallet. Is how I buy from dispensers, do you do it differently? (Or anyone else can also answer how they do it.)

It keeps getting repeated that this is about non-Counterparty wallets. It’s not. I do like it though. Maybe by me always saying it like this is why it causes the reaction it does lol.

I truly think the best move forward, in consensus, is to add the “create dispense” as a new function, but have a transition period where the good old BTC send still dispenses.

Then measure the adoption of the new way. Then, only after sufficient adoption, deprecate (remove) the capability for BTC send to dispense.

IMO this shouldn’t be too much to ask for.

the time between release and activation is the transition period...

It needs to be more than that, IMO

Edit: Actually, is not even what I am saying. This is forced.

it is more than that, there hasnt been a release yet

there hasn't been any code written yet at all. there's been a github issue and two days of conversations

most likely true

security through obscurity can end in tears, let's discuss the attack vectors in the open so they can be addressed before they can be used and result in losses

you'd have to know the implementation details of dispensers (specifically that dispenses are triggered by Bitcoin sends rather than by a Counterparty-specific method) in order to be able to conclude logically that a dispense of one asset triggers a dispense of lower-priced assets. a priori one would assume that by setting up a dispenser for asset A, they're selling asset A, not selling asset A and giving away asset B, if the price of B is less than the price of A.

that's exactly the problem: because dispensers are underspecified there isn't a clear distinction between the implementation and the protocol, and their behavior isn't well-defined, so you can't say what's a bug and what's a feature.

so far the two use-cases I've seen that will be eliminated by adding the CNTRPRTY prefix to dispenses are: 1. triggering dispenses from non-CP wallets; and 2. "cascading" dispenses (i.e. dispensing more value than was paid for).

(1) results in an effective loss of funds for the buyer unless they import their private key into a Counterparty-compatible wallet; and (2) results in a loss of funds for the seller, period.

In particular I cannot see why (2) should be considered a feature any more than accidental dispenses (which will be elimimated), or being able to (unsuccessfully) trigger a dispense from an empty dispenser (which will be eliminated). All of these use-cases are consequences of the absence of a Counterparty prefix for dispenses and they all result in a loss of funds.

how will dispenser over payments be eliminated ? the fee race condition is real

That is inherent in dispensers. What I'm talking about is the fact you can try to trigger a dispense from a dispenser that was emptied in a block before you broadcast your tx.

if your going to use your mempool to control tx hex generation ppl will circumvent the api and generate op returns manually so you will have two tier system

that is independent from what I'm saying...

we already have sanity checks for all other kinds of transactions. there won't be two "tiers" of uses. there will just be less loss of funds

For what it's worth, I'd prefer to remove dispensers entirely. They might add SOME value over centralized vending machines ..but do complicate the code, open up attack vectors and slow down nodes.

I understand it may prove impossible to reach consensus for removing dispensers, so requiring an opreturn message seems like an okay compromise.

adding an opreturn message will at least allow us to mitigate some attack vectors, reduce the impact on node performance and simplify the code. appreciate your perspective, JP.

Cp might fly under the radar still, until atomic swaps. Then when they're redundant they perhaps might aswell be removed.

17LV3y5KhExPdVcqS81zXuVUfNV9pmaGA

1ARxw3VTGYSeANnRyC52pH1cJ9V6HEXU8Q

JP making adding the prefix look like child’s play

Running a node with a blocksonly=1 conf will circumvent mempool tx generation control

If it ain't on chain it didn't yet happen n someone who is lead to believe the dispense is 'safe' due to sanity check can be gazumped n will lose funds exactly the same as they do now

it would be ace if fund loss was preventable

the solution is psbt atomic swaps. the issue is that with dispensers right now there is a needless source of loss of funds: since dispenses are triggered by btc sends you can send btc to a dispenser that was emptied in an earlier block and lose your btc. that would no longer be the case if dispense were a regular counterparty message.

I disagree .. your node with its sanity check may prevent tx generation but that doesn't stop tx generation by those who either disable mempool sanity checks or simply create tx with hex and not even bother with using the api

ppl who frint run their own dispensers are not gonna be stopped by a sanity check on tx generation

Obviously using the mempool for sanity checks should be optional, we all know mempool is different for each node

false sense of security js all the mempool can offer

False sense of security is all that dispensers can offer

jdog added mempool checks to dispenser pages on xchain to help prevent people buying when a dispenser was oversold, it’s one of many bandaids

Maybe dispensers should have a price ceiling like an actual dispenser. If you lose your $1 in a machine and don’t get your candy bar it’s no big deal. Problem is people started selling the equivalent of Rolex watches in these dispensers 😂

And utterly failed during xcp20 creating a false sense of security. Xchain would say they were still available when everything was sold out

It’s like we have a car with square wheels and everyone is giving suggestions on how to work around the fact that the wheels are square rather than just addressing the shape of the wheels

“But isn’t it great that the car moves!!”

I agree and a prefix changes nothing regarding security

I like the prefix, as I said, but it's not magic

There’s no claim at all that this is a catch all fix

it removes a handful of ways users lose money. it's not perfect but it helps. nothing is perfect as dispensers are inherently trust-based. but people like them

It is a fix to at the very least bring dispenses into the same structure as all other counterparty txs

People like them because there’s no alternative currently, people LOVE psbt swaps as we can see from the volume on magiceden

This is an incremental step to getting there

I'll tell you what, Joe, you propose we remove dispensers and I'll seek refuge behind the closest barricade

I think dispensers will still have their charm even in a PSBT swap world as you can create a thousand dispenses for a single txn fee. PSBT can’t offer the effortlessness of that.

Psbts cost the seller nothing

Just in terms of the effort (maybe can be automated away)

You create a single utxo binding Tx with 100 outputs then you can create a batch of psbt sell offers

Costs a single Tx fee for the seller

Well that’s good to hear. Seems like dispensers can eventually be depreciated entirely

Deprecated 😝

Spell check 😀

Not to be the language police but I can’t help but cringe whenever I see depreciated

Sorry Mike carry on

Having used magiceden a lot over the last year selling inscriptions it’s really the superior market design

You can post sell orders instantly for zero cost

Cause they’re just psbts

I’m assuming wallets can make this change ahead of the actual protocol change with zero impact as the header will just be ignored when buying from dispensers. If wallets do this soon, then we can kind of track when it gets to 100% compliance (or close) before flipping the switch on the upgrade.

it's changing a single API call and there will be a month between release and activation. there's no real reason to get ahead of it.

Yeah I think the actual sunsetting of dispensers will take a longer time period but simply adding the opreturn requirement is a great first step

Doesn’t hurt tho… and might help appease the naysayers if it’s for 99.9% compliance. It may already!

For all we know 99.9% of buyers are already using a cp wallet we just don’t know

I’ve been watching dans xcpbot for the last couple months, it’s a handful of dispenses a day, it’s not out of the question to make an update and do some outreach to let people know

His bot has a price threshold (I think) so likely ignores xcp dispensers

I see stuff as low as like $20-$30

I mean as Periwig pointed out before, we already need to tell people not to send from taproot addresses or they’ll lose their bitcoin

This is just the next step saying you need to buy using dispense function in a counterparty wallet

they also can't send from p2wsh addresses but afaik they are not warned about that

but yes, it is surprising to me that people think disallowing specific address formats is less of a mental leap than disallowing a wallet type.

The challenge is: what constitutes a CP wallet? Most would consider freewallet as *the* CP wallet and it’s unclear, at this time, if that particularly wallet will implement this upgrade.

That's not really fair. @hodlencoinfield himself is the author of a popular wallet.

Also a handful of stamp wallets

Yes. It’s popular but I don’t think I’m speaking out of school when I say Freewallet is bigger

'speaking out of school'. never heard that one. canadian phrase?

Those will implement the upgrade, I’ve already reached out

I would probably be using depreciated. Deprecated is a nice word.

btw, signalling early is a good way of figuring this out!

The fact is we’ve already seen that there are competing visions of what counterparty should be and we need to keep moving forward to stabilize the protocol even when the road gets bumpy

the CP community runs on freewallet, best is to compromise with JDog I'm sure you guys can work it out

If dispense is a counterparty message fund loss is still possible due to the design of dispensers .. I doubt anyone disagrees with that statement n that is all I am pointing out

a prefix makes dispensers marginally safer but scammers still gonna scam and no amount of sanity checking can prevent that

I don’t disagree with this

I don’t think anyone is making any claims that disagree with that either

The big win is moving dispenses to a counterparty message to drastically increase parsing efficiency

And removing addrindexrs as a dependency

I like the prefix , we all do, else we would not be here

It’s like how the reason to move to segwit was to fix Tx malleability and as an extra benefit you get effectively larger blocks

yes, they can only ever be marginally safer because they are inherently unsafe. however adding a prefix to dispenses removes ways of losing funds that are not inherent in the idea of dispenses. and it has serious long-term performance benefits. and it simplifies consensus critical code in the part of the codebase where nearly all consensus issues have arisen.

that's a good analogy!

But most people now probly don’t know that about segwit

And how much money was lost due to Tx malleability attacks on exchanges

adding a prefix to dispenses is about the biggest bang-for-the-buck change I can think of.

And it has some extra minor benefits that go along with it, like requiring a counterparty wallet and allowing you to open dispensers on an address you use without accidentally triggering them

But the biggest benefit is really parsing efficiency and making nodes easier to run and less complex with less dependencies

It will require its own UI correct? Like a dispenser button? Because CP wallets also need to perform vanilla Bitcoin txns

Yes

But it’s extremely easy to integrate, adding an opreturn output is not complex

cp api can detect it's a dispense purchase and modify the txhex to make it not need any ui change

I don’t think anyone is using cp api to create btc sends

i think freewallet does

Gotcha, was not aware of that

can someone help me to my concern

Like this one example

xcp . dev address/19Tu2YbsCMJn1BeYyfgg6qu3TEseBuifp4

What are you asking?

Why the assets disappear and the dispenser is closed

Because the owner closed the dispenser and debited the assets

Can you check this

https://xchain.io/address/19Tu2YbsCMJn1BeYyfgg6qu3TEseBuifp4

Look at the debits

How can it be?

If you check the txhash it says that he is using op return

So does the asset possible to return on its address?

But the asset is still on dispensing?

They closed the dispenser

Yes but how does the asset transferred?

I can't understand

What debits mean?

The close dispenser is not unconfirmed so it means the asset can be brought back to its actual address?

That address sent their assets out

why are you asking questions about stolen assets from 8 months ago?

because it's the same error on my address

what error exactly?

I’m a developer

A feature, not a bug

This is solved with UX. Put the block tip state, this is the timechain up to this moment you are looking at the dispenser state.

Is experiential, natural, obvious.

Even with its flaws, I think dispensers are amazing 🥰

🙃

Love you JP. 100% disagree. Being stupid simple is a feature, not a bug.

By being stupid simple it is flawed. Yes. Let’s improve them… by not breaking them which will 100% result in loss of funds.

Never everyone updates. Never.

Wow didn’t know this happened!

This for sure gives a different perspective.

Still, I think is just a UX problem. Poor usage of Bitcoin is not Bitcoin’s fault. Same for Counterparty. Why expect something different?

Then UTXO based assets are a no go.

Superior or just different? Counterparty is… the counterparty. Vs a company.

…

Wow 🤯

Instead of stable and consensus?

The requirement of a message (vs nothing required) is a usability downgrade.

Not a subjective opinion. Literal engineering.

Yeah, this will be the exact words from them people that loose BTC by sending it to a dispenser address…

Like they’ve always done.

And the code will be beautiful with a trust-required csv.

No “don’t trust, verify” possible from the “latest and greatest” updated Counterparty.

Progress.

Sooo... whats the final decision.

Why don't we do a survey on github? something like this:

Poll
We should implement prefixes in CP.

Pros....
Cons....

Voters example

Yes/no

Why?

Because matters of consensus don't actually come down to a vote.

Just recently a prominent member of the community held a vote for adding an XCP burn requirement to numerics. How'd that go?

It went great actually the entire active community supported it. Surprised your group of 5K bots couldn't muster up any votes

sad and pathetic, but mostly pathetic

I actively told people not to vote because that would just give it legitimacy. How'd it go great if the "entire community supported it" and yet nothing actually happened? Not sure why ignoring someone's poll is "sad and pathetic" but continue living in your alternate reality with your stamps derangement syndrome.

Mike in swamp keeps degenerating further... fun to watch

Living rent free in your head.

Will continually be here to call out your grift

Will Dividend BTC payments now also get the prefix?

From reading the docs there are 2 transactions that dont have the prefix .. simple btc sends e.g. those with no memo attached and btc dividend payments

btc sends with memos have the prefix

That's called consensus...

Bad idea, the small amount of people against it seem to be against every other fix, overly debating the small negatives vs massive amount of positives & trying to slow down development.

A lot of fixes are needed for Counterparty to be a competitive protocol, they should be allowed to get on with them

and that, gentlemen, is authoritarianism.

If the majority of people vote against something or in favor, it is obtained by consensus. in bitcoin they are the miners and nodes that use "computing power" as a vote.

but in CP we do not have mining or nodes with consensus, make a poll and let them vote.

you "vote" with the version of the software you run... just like in Bitcoin..

but CP nodes can't communicate with each other....

So no node consensus

bitcoin's consensus doesn't depend on nodes

you run the version of the software you want and that will determine which network you're on.

UASF was a node thing

Of course yes... bitcoin cosensu depends on the nodes.

no... it doesn't. otherwise you'd just use a regular bft consensus algorithm

nodes can be sybilled

this was about miners following the economic consensus, which has nothing to do with formal voting procedures.

UASF nodes said nah to 2X

Ok so use bitcoin version 0.1 and try to synchronize it with the others,

there has been a mandatory bitcoin upgrade since 0.1

if nodes had not uasf we would be 2x

big players decided in a back room the upgrade path ..was not formal voting .. nodes then said UASF .. again not formal voting but demonstrated miners are not incharge

You voted

I want to make some sub assets but I feel grifted having to pay xcp charge when numerics don't have to

But yh all 3 voting mechanisms where in favour of xcp fee on numerics, chat vote, project vote and xcp holders vote, along with the original vote in dev chat to add the fee

And what happened in spite of the overwhelming “support”?

Stampcoin did what u wanted them to do

Ahh yes. I’m in charge now. Lol

xcp holder vote and project support lost. The vast majority did not “vote” btw which in essence is voting for the status quo.

Something like 1% of xcp holders “voted”. 99% were happy with the status quo

Most projects didn’t vote

Is that how votes work, in elections, those that don't vote have an impact?

In consensus systems they do. The status quo is the status quo.

This isn’t a democracy. Some people think it is.

I think that voting mechanism has been used in CP history and uncast votes didn't have effect

No it is clear that people's votes doesn't count

Again I will point you to the real world result.

btw, the idea that CP has turned into “post office coin” is absurd. I have very little influence over anything. I’m not a coder. I don’t run a node. I’m just a loud mouth on twitter.

You are In the dev chat along with stamp devs that consistently used their "loud mouths" to get CP working on your terms

“Our terms” are merely the status quo of how CP already works.

You wanted updates to wait for you etc etc

What updates?

Is a pointless conversation, post office coin has won, people votes didn't matter, original dev vote didn't matter, and I have to pay xcp for sub assets that can't be squatted whilst you can flood numerics for free, as you say this ain't no democracy

I was going to refute your point above but I’ll leave it be. Let everyone believe I control CP 😁

Ok lets do it. Lets force cp features....

If the community does not vote, the devs vote. That is already consensus.

You don't need to ask each user.

I agree with everything they have proposed lately. except for attaching the assets to utxos.

Attaching assets to UTXOs gonna be interesting as it creates new ways for users to lose assets / value

The reason why voting doesn’t work is because you can’t compel someone else to write or run code. You’re either with the consensus or you fork off and attempt a new consensus.

there is a world of difference between inherent limitations in a feature and implementation bugs.

users can be very creative

formally designing a feature and specifying its limitations and attack vectors is a normal part of designing security-critical software.

implementing a feature and then discovering attack vectors that weren't considered as part of the design and then treating those attacks as features is not.

this is a requirement for a feature for which there is not just demand but a mandate: psbt atomic swaps.

I would not be surprised to hear someone spends a utxo that had a asset attached and the asset is then lost

you can't stop people using private keys in non counterparty aware wallets .. lots of users consolidate utxos using non counterparty aware wallets and are encouraged to use Electrum for this as there is no Counterparty aware wallet that has coin control and an easy path to utxo consolidation

the solution to that is to build Counterparty-aware wallets with coin control surely?

having a particular private key in multiple different wallets is quite standard behaviour

I don't know what to say to that. If you try to make txs from a Counterparty address from a wallet that doesn't support Counterparty, you will have problems.

I see warning to not do this I guess because people do that

That is understood, but the specific reason you gave for importing into Electrum can be addressed with improved wallet software. It's a big feature and it will require new kinds of software to be usable and safe.

I think there is an incorrect definition of what a wallet is.... the wallet only stores the private keys and signs tx, it does not have the responsibility of managing assets. That is done by third parties, in this case they would be dapps....

buid in front, sign it wallet.

Counterparty isn't Bitcoin but it's on Bitcoin and can interoperate with Bitcoin thru UTXO binding. People like that but there are downsides.

Mark that words

XCP is the Bitcoin inside Bitcoin

Ser XCP is a shitcoin. Casey said so.

if you attach assets to utxos then xcp would become a bitcoin tx marked.

Yes.

If it wasn't necessary then sure it is less likely to happen, but there is now a culture of exporting private keys and using non counterparty aware wallets with keys previously used for counterparty activity

If you're saying we shouldn't have psbt atomic swaps for that reason that's not an unreasonable position, but the community seems strongly in favor of it.

I am saying expect users to do things that could lead to asset loss

Sure but once again there is a fundamental difference between losses of funds that are inherent in a feature and losses of funds that result from implementation bugs.

attaching a asset to a utxo makes it possible to lose it .. by design

brother, let's not complicate things, let's make things simple... let's take precise and accurate steps, your time is worth enough not to spend it talking about who is right... .....

Yes, but to bring this back to the issue at hand: you can have dispensers that eliminate a number of different ways for users to lose funds (by adding the prefix) but you can't eliminate loss of funds entirely.

what? no

I attach asset to utxo

I then spend utxo

asset is left hanging

He's saying if you have your Counterparty addr privkey imported into a regular BTC wallet and then you send your BTC from the latter you lose your assets

this chat has already turned into a play where the participants are measuring who has the biggest dick, on their arguments of why yes and why no .....

@B0BSmith that's not how it works. please read and understand the actual proposal before commenting on it

we are in a circle where we always come back to the same thing.

Basically we’re arguing which way is best to lose your money using a dispenser

@teysol because of the ability to unbind we're not susceptible to this way to lose assets?

The one way you should definitely not be able to lose your assets is by sending Bitcoin to your own address.

i lost around 500 xcp using dispensers.....

So has everyone else. Welcome to the club.

but no one will help me with that, I understand what it feels like... it's my fault and I accept it, we move on.....

What did you do?

i sent from a exchange to my wallet....

Yup, def number 1 loss of funds on dispenser, rugging yourself

Which the prefix solves

and I didn't remember that this wallet had an open dispenser.

so thats ok...

instant ban

yo

nah, if you spend the asset to which the utxo is attached you lose it. same issue as with ordinals etc.

The main purpose of a Bitcoin wallet is to send and receive bitcoin.

If we can’t do that just because a dispenser is open, you think fixing that would be a main priority 😂

Cmon man

Some of it is way above my level of understanding .. as I don't trade ordinals with psbts so got no experience of the tech

JPJA raises the point about allowing origin address to reclaim token but quite sure it was mentioned in another chat recovery would not be possible .. so its hard to know what and what not is possible until there is code we can run

Just curious tho: if the UTXO is spent without the corresponding header in the txn, why couldn’t the asset be “un-binded” at that point?

thats a good idea...

this is what I was wondering @mikeinspace. not sure!

so there is a recovery mechanism ?

surely we can... like a bridge between op_return and utxos..

it's a big win if true so I don't want to make an unsubstantiated claim.

If this can be solved CP suddenly leap frogs ordinals as the resilient solution.

FUD ordinals to death lol

lol I don't think it's possible but would be amazing.

yeah no definitely not possible

if there is no cntrprty prefix its not a counterparty tx ..so spending that utxo without the prefix does what?

You’re already doing that!

Seems like it could be possible but maybe I’m overlooking something critical

the whole point is to make moving counterparty assets compatible with Ordinals, Runes etc.

While attached to a UTXO

so once the Counterparty asset is attached to the UTXO, it looks exactly like an Ordinal

the asset is either stranded or is 'recovered' to the address that made the utxo but didn't include a cntrprty prefix when spending ?

Thanks

assets don't get "stranded"

once the Counterparty asset is attached to the UTXO, there's no prefix for transfering it... or you wouldn't be able to move it around

so a asset attached to a utxo that is spent without a cntrprty prefix goes where ?

I'm not going to discuss the proposal with someone who hasn't read it.

once someone has read the proposal, they can ask questions about it if they don't understand it. but then they don't *also* get to make bold statements about the features of the proposal in the same breath

I dreamed for a moment.

https://github.com/CounterpartyXCP/Forum/discussions/134

I have read discussion 134 like I said I don't fully understand it all so am asking questions in a effort to better understand

jpja raised simular concerns

I'll wait to run the code n play with it before asking more questions

Users will always find a way to lose their assets, people lose bitcoin too btw

thats right

having a key in many wallets is dangerous but ppl do it

Yep people do a lot of things they shouldn’t wrt crypto

humans are expert in this

Bob I would suggest playing around with ordinal psbts, download xverse, buy some cheap inscriptions, put them up for sale, etc

It is amazing how well the structure works within the scope of Bitcoin

I guarantee anyone that does that will be pro utxo binding in counterparty

ty I will give it a go

People do this due to the deficiencies in current cp wallets. It’s forced users to share keys with electrum and others to do basic things like consolidate UTXOs. Hopefully, better solutions emerge so that this bad practice is less likely to happen going forward

https://github.com/CounterpartyXCP/Forum/discussions/134#discussioncomment-9420279

look on this...

i am not opposed to the idea.. I just think you got to be very careful as users are experts at using things in ways they were never intended .. either by mistake or intentionally/maliciously

Yep it’s up to wallet developers to help mitigate that as best possible, I think best practice will be to segregate asset bound utxos to a different address, this is how xverse and other ordinals wallets handle things

Just a little more arguing to prove we are decentralized and we should be ready to go with the prefix change

maybe a different path is a good idea incase a user consolidates across a xpub