Still need to set the scale

for costs to change state to user yeah. 0.1 xcp is 0.1/2613892 of supply or 3.83e-8. change that to 3e-8 of unburnt supply as a single cost. emission rate small at like 10 xcp every 2 weeks isn't going to change it much and would be as predictable as possible. set other costs as multiples of 3e-8. people using old fees would still be fine for long time as it's already under old fixed size.

When will the fork activate on testnet?

What's the ETA for the anti spam stuff? Lots of stamp vaults being made and I'm hoping they are non spam stuff sooner rather than later.

I hate that vaults are mixed up in all of this. So am relying on the protocol to filter them out.

Oh so your sayin we should make up more protocols and hype them up and get a bunch of Chinese users to buy in thinking they’re going to get rich?

Eh? No.

XCP20.wtf

Sir xcp-20 has been here since 2014

It's the future.

How forks work is we roll the code out and then it gets activated... so, testnet wont have the feature until we put otu a release.... if your asking how you TEST the release / PR on testnet.... You run a node, apply the PR, then run fednode rebuild counterparty counterparty-testnet and then your running the new version..... I did this 2 days ago on a server and Joe has been testing the Numeric Fees PR on testnet

Sent you details to test on dev server in DMs

It’s the past AND future

Those are fake. There is only now.

Unfortunately, not sure it is CPs job to filter these out at this point.... I think best we can do is put anti-spam fee on to make it more epxensive to spam, and focus on removing non-usable data from the database.... As far as filtering out numerics..... That is still an option on xchain.... Tho, not wanting to penalize ALL numeric assets because of the actions of ONE project.... so holding off on the "nuclear" option of removing numerics entirely from xchain.... but if your looking for a "filtering solution"... yeah, could make it real easy for you and just stop displaying all numerics on xchain..... again, not what I want at this time tho... think "Bitcoin Stamps" (the non SRC-20) shit should allow to continue to operate on CP..... still feel THAT community has some potential to become CP users... but the SRC-20 stuff... naww.... they will never be CP users, so happy to keep filtering those out.

https://twitter.com/mikeinspace/status/1664242261528330240?s=19

That meme is so good.

It's really funny.

FWIW, the SRC20 folks will likely fall on their face miserably without CP.

But solid af meme.

Ugnh... more of this nonsense doesn't help... "Bitcoin Stamps doesn't need counterparty".... we working on something way better.... cool... then WTF did you use CP in the first place? Make up your mind mike... is CP cool and you like to use it... or it is a shit-platform that stomps on innovation and you are wanting to move to something else..... either way is fine... but cant have it both ways... pretend your a friend of CP and onboarding ppl... and at the same time talk shit about it

FWIW, he has to say that.

Publicly. Shit has gotten out of control and he's seen as some sort of Stamps Jesus.

Or Moses.

Or Allah.

Mike will experience the pain when src bag holders blame him when it doesn’t work out

All we can do is move forward with aligning the Counterparty ecosystem

Yeah. I feel bad given the oncoming Chinese wrath.

https://twitter.com/wasthatawolf/status/1664276281184354308?s=46&t=csXvDn2SopzSbnOM0eLdDQ

He won't even be able to read his hate mail.

I hope so... but sure seems like he is doing what I had feared.... taking stamps inability to use CP and weaponizing it against CP...... what is easier path "I made a mistake, I was wrong"... or "Fuck those CP guys, they made our life difficult, look they even put a numeric fee on to stop is"..... we all know it is bullshit, but.... I'm asking myself based on his past actions what path I think he will take..... which is why I am concerned when I see this kinda stuff.. Either way... yeah, all we can do is focus on CP and let the chiops fall where they may.... He wanted attention, he got it... lets see what he does with it 😛

Nope. I take zero responsibility.

https://twitter.com/mikeinspace/status/1664277123480326144?s=20

Probably too late for that.

SRC20 has your implicit...

...stamp of approval.

that has been clear since the SRC-20 devs took over your project... happy to just let ppl do whatever... as long as it gets you more attention... at least, that is my observations.... Think your a smart guy, love what you did with Bitcoin Stamps initially... but you lost control, and this is the result of that... you wanted to do a net positive for CP, and instead you created more drama..... again, all is fine, but just want it clear that this is a choice you made

I've been clear all along. People can assume what they want.

Assume they will

Lost control assumes I control an "open protocol". The entire point of being "open" is that no one controls it

Yes... assume that the creator of a project steers and guides that project.... wrong assumption I guess

guess I misunderstood your goals then.

Lol

https://twitter.com/mikeinspace/status/1664003966143721481?s=46&t=csXvDn2SopzSbnOM0eLdDQ

Looks like support to me!

That's support? Nah that's just an observation.

Hahaha tell that to the Chinese

Don’t worry we’ll send them your way

I've gotten way more hate over my dabbling in XCP-20 fwiw... people real mad wasting Bitcoin...

Those are your people mike

They’re gonna be real mad when transfers never happen or when they do and they all get dumped on

Transfers will happen... not getting dumped on isn't something anyone can promise. I'm sure it will all go to zero.

Mmhmm

Did your team of devs tell you this?

Or is it a third-party doing it?

For your sake, I hope a third-party.

I don't have a team of anything. I have seen demos and the tooling looks real good.

I LOVE THESE MEMES.

Bro the 3rd party is gonna build it!

Demos lol

If the tooling looks good, confirmed 3rd party.

Excited for the indexer. That won't be a catastrophe.

3rd party services are the way for SRC-20... why build it when you can rely on others to run your shit for you... explorers, wallets, indexers

I can’t wait!

They’ll just run a Counterparty fork cause it’s easier

Hola Jake

ello friends

🧣

@jakegallen .https://t.me/Counterparty_Dev/4775 drama with SRC-20 starts here.... enjoy watching it all unfold... you'll be able to see there is a LOT more going on than what is being sold to the stamps community.

Making history

ultimately this should all be captured in some meme assets, the best thing about rare pepe is it's encoding history

https://twitter.com/wasthatawolf/status/1664281000539717635?s=46&t=csXvDn2SopzSbnOM0eLdDQ all the bsvers in my replies tells me I’m doing something right

cannot wait for the movie

The replies here are great, boomer.

This is awesome.

was lazy to write the text, but took the time to edit the date

Thanks

I went to look how to mint last night…

Pay in BNB or ETH. Can’t even pay in BTC.

Just want to say that my meme post was just a poke at feud happening here. We are all memers afterall. Don't want to take sides but would like to offer mediation or support anyway I can if there's a route to help remedy the situation or help share the complete story.

Can host a public spaces so all sides can share info, emotions, and work on some solutions. It appears there is some lost information that many are unaware, including myseld. So just wanna throw it out there as an option to help. No tough feelings towards anybody.

Nice we made bitmex! Do you have a link?

We love you jake

😁

Dammit got my hopes up

I pinged the only researcher I know focusing on forks and clued him into the current situation so hoping he makes a case study out of it

STAMP_WARS of 2023 hypercycle still playing out... wait another couple months... someone def gonna write articles about all this src-20 drama 😛

It was such a good meme.

I would be open to going on a twitter space... but, this would be a HEATED topic... so, would need a solid moderator to tell ppl to stop talking (myself included) and to let others speak..... Provided we have a solid moderator who will let both sides speak... I'm down... Would want Joe, Mikeinspace, Reimnora, and myself on any space.... we all have been involved in the drama since the start, so have the most accurate picture of what happened (from both sides/perspectives).... really tho.... just want to move past all the drama and have src-20 go off and do their own thing

And I'm saying that as a XCP maxi.

It wouldnt be heated and wouldnt even be a debate. Probably an hour of me just agreeing with you and saying "well its an open protocol I can't control what usecases spring up on it, good or bad..." anyways, I'm all talked out, I've been doing podcasts and investor calls every evening. I don't think I have time for a spaces.

QQ, BTNS is still unprunable?

BTNS is a protocol for creating tokens in the most open/easy to understand way..... I dont layer on any additional nonsense like keyburn requirements or multisig requirements... if a PROJECT wants to put those requirements on a BTNS token to be included in their project, that is fine... but those requirements do not belong in an OPEN Protocol.... TLDR, if you want you can make a BTNS token "less prubable".... I dont think anything is "unprunable" 🙂

I just wasn't sure how broadcasts work. Are they still at the lowest lvl just a Bitcoin tx?

Adam and I would be open to moderating and being concise and objective with the flow of conversation. Also open to suggestions for moderators to co-host.

Clearing the air is a good thing or at the very least getting some closure on the situation. Would be good for the public to hear both sides.

Just an option 🙏🏼

The name makes me think of events broadcast usong bitcoind, or Ethereum chatter over whisper.

You realize they are selling a mint for tokens that do not exist, cannot be held in self custody or sold.

I don’t understand why this is controversy.

Literally taking money on a promise.

yup... broadcasts are just using CP encoding to write some text to bitcoin blockchain.... BTNs doesnt technically need to use CP or the CP broadcast system... just needs a way to write the BTNS format to a chain and decode it.... BTNS uses CP broadcasts cuz it is easy and ready to use now... but, could easily take BTNS format and roll it out as its own thing

kinda what I was expecting the src-20 guys to do... but, they forking off rather than pivot to broadcasts... which is fine 🙂

Cool.

How much more self custody can you get than the token being in the minters wallet? It’s really no different than buying an eth token before there is a liquidity pool.

What token with what wallet? CP reads 0 tokens.

CP founders in 2014: we’ve built this revolutionary platform on Bitcoin for free and even we have to pay an equal share of our own money to be included like everyone else.

SRC-20 founders: buy our tokens for this new Bitcoin platform that’s not released yet and pay using BNB or ETH. We are making loads money even though we’ve delivered nothing.

Honestly I’m shocked you can’t pay in Bitcoin. That might be the funniest part of it all.

Why even use Bitcoin.

the src-20 community lol https://twitter.com/reaperRTX/status/1664298776738111489?s=20

the irony of all the hate im getting on a post where no lies were told

Stamps are cool, SRC20 is scam and spam. It will be sad to see stamps suffer because of SRC20

The tweet sums up pretty accurate

I concur, I love stamps

That's the thing, an indexer needs to be written. That'll make it all "real" (lol, like any of this is real).

I'm bearish on an indexer being written. Super bearish on it being written correctly.

I can't comment on "correctly" but indexers certainly aren't vaporware.

https://crypt0biwan.github.io/src20/

https://coinranking.com/coins/src-20

https://stampcoins.io/

https://www.stampscan.xyz/

https://twitter.com/hirowallet/status/1664025629392613377?s=20

Those are dashboards... where is the open source indexer code so that everyone can review the code, find flaws in logic that one programmer might overlook, etc.... Are the indexers going to remain closed source black boxes? Is SRC-20 team even working on an indexer? or are they waiting for someone else to do that work for them as wel?

Hi guys, just want to show you a wallet poc we build. The data is real.

excellent... you have APIs that show balances... how do you get to those balances... an indexer... where is the indexer code?

dev details... i have no idea... probably parse the blockchain

Not attacking... just saying... feels very strange to have ppl saying "we have a wallet, we have balances"... but no one asking "HOW" did you get to those balances and "HOW" can I verify your not just making it all up?

Well the original claim by @AryanJab that I was trying to address was that this was all vaporware. The how is a different question. Don't know, not involved.

Got ya... yeah, something is being written to show balances and stuff... def not vaporware... just unclear if it will be open-sourced or a black box

open source software and peer code review are the way forward for indexers 🙂

It’s all open. In fact competing services like stampsbot.com exist.

we are not using "open" in the same way

but got ya

There's literally nothing proprietary in any of this, because that would be impossible to implement. Is Keyburn hard for the average user to do without tooling? Sure. But its not our job to build free tooling. Anyone else can though.

"open" in that anyone can build competing project and minting service... is not "open" source software where ppl are cooperating.... ideally, would want to see 5-6 "open source" indexers so that they all can comare with one another, make sure they are getting to the same data, etc.

I agree

Most open source projects are "closed" to me because I suck at coding. Are they closed source because they are above my skill level?

I imagine it will be difficult to gain adoption and integration from wallets without an open source reference implementation that proves how balances are arrived at

Regardless of views on src20, an indexer that can start from an empty db and arrive at stampchains results is needed

I started tinkering with one myself and ended up with different results

Lol nice video I remember fabrique making one just like this a year or so ago

Fabrique released his wallet. I've installed and used it. Pale Moon.

Nice

And I do mean tinkering, I was mostly trying to determine what is/is not a stamp

agree 100% there are two indexes now one for the legacy CP and one for the new protocol so the trick is merging all that together in a repeatable open way.

irt to the database, on a relative medium/low capacity server I get these query times.

275,825 total issuances in CP db - real 0m1.932s

117,172 total numeric assets - real 0m0.955s

74,082 numeric assets with 0 qty. - real 0m0.648s

This is the bloat we are talking about. I still don't get how anything less than many millions of records is considered bloat and creates such a fuss.

we all trying to figure that out 😛

if it's a stamp:, numeric asset, and a valid base64 image format. and multisig, that's all we are checking. there are some anomolies from prior versions of indexing as we grew with lessons learned, but we do expect it to be easily repeatable by anyone. Constructive feedback is welcome. we have shown our proof of concept is a success so we are going back to rebuld in an open way with transaction construction that doesn't require additional tokens to create.

But the src20 is just a base64 json string?

so stamps are "base64" and not "images" huh? Learned something new today... I heard from Mike earlier that Stamps were IMAGES... and that he wants to get stamps back to being just IMAGES..... guess the CREATOR of Bitcoin stamps and the SRC-20 devs have different understanding of what "stamps" are..... yet we are supposed to make sense of all this.... when you guys can't even figure it out yourself... lol

bro... scroll up... its been explained to you at least 5 times in the past month... not wasting any more time on your not understanding... either you dont get it, or you fake like you dont get it... in either case, time is wasted trying to explain it again.... scroll up or have someone else explain why it is an issue..

Src20 are delivered in an SVG envelope which allows them to render in an <IMG> tag.

Well that’s not really fair. The image needs to be encoded somehow. My main question revolves around other data types that are considered stamps.

Src20 are “images” from a technical standpoint

That may be how they are presented to the end user, but if you look at for instance the kevin deploy stamp, it’s just base64 json

i said "base64 image format" who said anything about not images? the whole point was to be an art meme project

are they? where is the image data encoded?

Talking about the src20

got it... I must just be wrong and confused... thanks for explaining it all to me.... much clearer now 🤷

it's encoded in web 2.0 to save on blockchain space and reduce size/cost ofc. no different than a XCP token json pointing to an imgur url.

I did say that I hope "art" returns to the forefront, 100% I would prefer that to SRC20 dominating stamps.

So it sounds like @reinamora_137 is working on moving src20 off of xcp and onto its own protocol. If that is done in a reasonable timeframe does that remove the chance of an xcp hard fork? @jdogresorg

we are using json in a CP description field in a database with a mere 276,000 records. it's quite hilarious that it reates so much fuss.

not really (as in the hard fork) because art stamps are targeted with the xcp fee - regular stamps are what is consuming the database size. src-20 is negligible by any way you look at it.

I suspect it's about the future, Bitcoin should be viable for hundreds of years, same for CP. Bloat isn't about current size, as much as potential noise forever that will grow exponentially

exactly that's why we are moving src-20 off of CP now that we have seen the proof of concept play out.

U are selling a promise of right now. Stop ignoring that fact.

Funniest thing to me is this whole debate seems so similar to why Bitcoin proper hates ordinals... Useless bloat and tooling that's got to be made and optimized forever

a promise of what? I made no promises, only state what we are working on. we enable users to mint art on btc and we are building things around it.

Is the xcp fee for numerical stamp creation still planned even with src20 migration? Since dispensers are regularly used to buy/sell art stamps, Doesn’t it make more sense target that transaction with a tax?

Ideally in btc

Shame you couldnt have just paused your minting service for 1 day and pivoted to the BTNS system and SRC-20.1 spec I wrote for you 3-4 weeks ago.... had you listened then, all of this could have been avoided.... github history shows, I tried to guide ya bro... but you know best for your project... which is fine... but lets not forget, you had help, you made a choice to go a different route... your seeing the results of that now

https://github.com/jdogresorg/stampchain/blob/main/docs/src20.1.md

we could have if you actually took a minute to talk to us about it and understand the needs and requirements prior to just throwing something out there for public consumption that wasn't a fit for what we intended.

Now wait, don't rewrite history.

The back and forth was massive before anything went public. Pretending otherwise makes you look... Well it's not a good look.

Cmon bro... I created STAMP DEVS channel to organize devs n get communiations going... you rolled SRC-20 on your own, didn't ask anything... and I had to scream and holler to even get your attention.... lets not play games... YOu were focused on src-20 and he hype... which is FINE... but, dont pretend that this was something forced by me.... I saw an issue, I did my best to make you aware of the issue, and wrote doc/specs to solve the issue..... If you choose not to pay attention, that is on you... github history (and devs here like @shannoncode ) know the true history man.... Maybe you truly just dont see it cuz you see me as enemy now... .but honestly, I tried to help guide you guys before it came to this

we only had questions on some techinical details regarding it, and potential restrictions that we weren't getting constructive solutions to

"Hey guys, BRC-20 is new, how can we do someting like this on CP"... one question.... engage with teh community your building on... would have solved all this... but instead you decided to start shitting in the sink because you couldn't figure out the toilet.

no enemies afaik. the simple fact is that we didn't see a point in shutting the whole thing down while we simultaneously worked on a new solution that worked for everyone.

We also didn't think storing json strings an an asset would cause an uproar. it's done on many assets in the db

Understood... hopefully in hindsight, you see that stopping the service and pivoting would have been good

FYI... you STILL can do that

BTNS is there

i could see more of an uproar regarding stamps. that's the data usage

Not agreeing with the problem/solution is a much more accurate description of events.

indexer written... happy to work with you... but this src-20 shit has to stop... and it hasn't... so we gotta move forward

but my door is still open.... once spamming stops

we have simple plan to get file data out of database... so file data in cp database is shor-term issue.... bigger issue is non-usable assets we have to live with forever

anyway... I think the die has been cast and your going to fork off... but, want it clear, even after all this bullshit... STILL open to working with src-20... but you gotta actually work with us... not play games.... not focus only on profit, etc

they can be parsed and stored in another table.. we aren't talking a ton of records

yes... given enough time we can definitely deal with them

but exploding the database without a clear plan to deal with it is not a viable path forward....

hence the need to stop the spamming... tried with words and worked for a whle with the "ceasefire".. but, resuming spamming just said once again "fuck you guys, imma use this platform how i want"... which again, is FINE... but, dont get upset when we decide to rearrange the bathroom cuz your shitting in the sink

anyway... all of this is moot... we dont need to keep going around and around

@reinamora_137 Are you planning to fork src-20 to something else or use BTNS?.... that will basically determine if I continue conversations... or are just hollering at one another and not making progres..... what is best for us all is to focus on what is best for our projects.

nobody is focused on profit here. I don't see where that came from. We did say that a little bit of revenue from the minting service could help all parties involved for potential dev resources (bounties, etc) and solving things for everyone. Nobody is getting rich here, this is all just for fun anyway. definitely too distracting from the day job when it's just a hobby to contribute to the community

Those are some of the technical challenges we needed time to process and figure out.

Hence why we didn’t want to kill the current revenue stream abruptly and kill any profit potential for both us and xcp

as mentioned. we are planning to pull src-20 out of CP into our own btc transactions that are parsed directly into our db (in a repeatable and open way). attempting to merge legacy and new transactions.

we are undecided on how to handle the xcp fees on regular stamps since the project was built around not requiring another token outside of btc to create them. This will likely require a fork and new infra to support non-xcp fee stamps ecosystem. (whch takes away from our time of building the src-20 stuff).

happy to dig up any comments irt the $ but it always has been a factor to 1 cover our extreme costs of virtual server usage and help towards any dev work is all. No different than if we sold a few stamps to accomplish the same thing. So why would we kill that revenue stream - or why would we cancel potential sales of stamps to cover costs?

Cool... forking SRC-20 away from CP... Thank you for the clear answer 👍️️️️️️

i said undecided lol

correct we don't need and don't want to use the CP database for those [src-20]. that is not a fork of CP

a fork of CP is a decision that needs to be made for regular stamps that will take away from our time in transitioning to a new protocol for src-20. I've said before. this is a hobby, a side project to have fun. we had a proof of concept that was a success and we are building based on that. that's all i have. i have no reason to stress on it.

The interesting thing here is that a fork won’t have replay protection, so any actions done on one side that are valid on the other will happen to both

this comes out of my pocket unless there is some sort of revenue stream. which you had demanded to shut down because of a few records in a database.

we aren't pocketing a bunch of money and running off. we are simply investing and building.

this whole false narrative of simply wanting money is way off base. I don't mind taking money out of my own pocket (and have) to cover startups capital, but that can only go so far

Wtf. How?

Wtf are you paying $11k a month for

Lol

That's more than SC spends. Lmao

Jfc

aws bill

I repeat...

This is my biggest concern and the entire reason I started reaching out about this.

ramp up costs, getting things contained for this month, but a threat of killing off all revenue has serious implications to my pocketbook

It’s highly undesirable

Sir you probly shouldn’t lecture anyone on efficiency if that’s your bill

haha, in a hurry to make things happen 🙂

There must be servers for other projects in that bill. That propostero...

Guys, how do you propostero?

Proposterous

Popostorus

i'm curious how this will play out as well

Popastasaurus

You’ll be on a minority fork

Yeah. It'll be like 4 nodes vs. 1.

My suggestion would be to add replay protection like the bcash devs did

Economic nodes matter most

Xchain, emblem, dextrade

All nodes matter, imo.

That's just my opinion.

ANM

✊

Lol

All you need to do is tweak the CNTRPRTY bytes in the message

yeah, basically that's what we are doing for src, but could be ok for all stamps and keep it simpler

Just activate on the same block as next Counterparty update and you’re golden, everyone will still have double stamps but at least they can send them separately

https://github.com/CounterpartyXCP/counterparty-lib/blob/09b20b3e1848481bed2fec3dba10c4cc11e5095e/counterpartylib/server.py#L369

Giving specific line they need to change in fork to fix replay protection... just change this string

They don’t even need to wait

Could fork right now since you have all your own tools per @mikeinspace

I even saw a demo video!

Then we don’t need to argue, you can be king of the castle

the tooling so far isf or src-20 outside of CP. we had intended to keep traditional stamps as part of the CP ecosystem since previously those weren't under threat and can provide a broader audience to both cp and stamps. nothing is definitive, and i sure as hell don't care to be king of anything lol

I've spent the last 72 hours minting 600 stamps, as much as I would like to make them magically 1200, please no

If possible, it would be in everyone’s best interest to move src20 and leave stamps as is.

Ser... I regret to tell you... https://twitter.com/0xDerpNation/status/1664285090351038464?s=20

Yeah…

I've saw it! pretty dope

Well I don’t know if that’s a problem

It actually helps xcp by storing less data and having more assets

But I have stored 600 karens raw images already onchain 🤓

150kb bitcoin spam

Is she here to talk to the manager?

To all of them

@jdogresorg do you see this as a problem?

i hope you know thats what you'll be if you fork

and you are king of src-20

everyone is waiting on you

and i hope you plan to support it forever

otherwise your userbase is going to be very upset at @mikeinspace

Not many people realize the weight of such a thing.

Some days I envy the anons

Have you got a book with conversational chat attack vectors? Or is this pure desperation?

im just being honest with you guys

not my first rodeo

I'd buy the shit out of this book.

fucking reorg again

ugh

792379

phantom or normie reorg?

looks like a normal reorg

kew we good then

plus your other node thats reparsing wont even know it happened lol

That’s easy. Jdog does nothing at all.

theres an idea pervasive in this space that software runs itself

It's rubbish.. you will be the fork

hahahahaha

good luck stampy

I'm just 'being honest '

fork you stampy 😘️️️️️️

I just want it to be over

you know this isnt the first counterparty fork attempt right?

No of it is fun

you can stop at any moment

agreed... so tired of drama...

I think I have

Anyone wanna buy any ordinals?

its a shame you guys didnt want to work together

I did and I tried

actions say otherwise

Meh

And even deeper, that software is easy, just add a new feature!!! Ugh each new point of complexity exponentially puts every other feature at risk of growing bugs.

and now a 9 yo protocol has to support assets created over those 9 years

https://web.archive.org/web/20180202235724/http://counterparty.cash/

We should get a pool together as to the date of the SRC-20 trainwreck.

When does the money stop? I pick that date.

lol

can we place bets on when/if transfers are added to src-20?

can i short src-20 tokens?

Ser, there's a demo.

I have actually one book like that for human resources performance management reviews :)

dammit you're right

just feed the demo into chatgpt and it'll write the logic for you

And then devs will work for free to launch it on a server that costs $11K per month.

I can get servers for $11 per month?

Hahah I can’t believe this lmao

Didn't $TURBO start with $69 and ChatGPT?.... #JustSaying

but then, NOTHING started with NOTHING but a tweet and raised $1M in 24 hours

I still don't see what Pauly did wrong there but we digress.

Like, it was bad of him to take advantage of stupid people but that's old news in the crypto world.

sure, he did 'NOTHING' wrong... but did he add or subtract value from people's lives?

anyway...

I've followed most of this SRC-20 discussion... I thought the pausing of minting to work through for a resolution together was a logical point where it all could have been worked through

but it seems it's all gone past that point now

don't have any great insights to add, but just seems like a missed opportunity for @reinamora_137 and @Stampchainofficial to work it through with @jdogresorg to have resolved it all within the Counterparty protocol and DB structure

I suspect a lot of the $1M was some inside joke larping between Pauly and some mates.

Ego is a bitch

you can still do this even after an update, itll just cost you a couple hundred dollars in XCP

thats whats so funny about this whole argument

numeric assets were barely used in counterparty for the better part of 9 years

stamps devs decided to use them as a data store and as a result it makes sense to apply a minimal XCP fee to nudge that use case to broadcasts

but people are acting like the sky is falling

I meant having them dupe

thats on whoever decides to fork

i know what version i'll be running

XCP fees are applied to various functions in the protocol, its nothing new

for me the XCP fee wouldn't have been a big deal, bought XCP for it when started with the karens just in case

it wont be a big deal for anyone

its very easy

lol

why its created a shitstorm i dont know

for newcomers would be cool to guarantee there's trustable liquidity available (dispenser's fear on the street)

Nifty, godbless you

yep trusted dispensers are the easiest way to mitigate that

Spending 18$ in btc fees for $5 worth of xcp wasn’t fun.

500$ worth of xcp cost me like $1200

Not sure if it was a dispenser thing, because it only was emit of 1, but I have to say the acquiring xcp experience was absolute garbage. And nail biting

did you use nifty's trusted dispensers?

I spent $14k in the fucking karens, where's dorian? want to speak to him lmao

nope I used xchain dispenser list and sorted by cheapest

surprised people arent selling XCP in emblem vaults

and don't forget your major role in this decision from the start of stamps. it was through your feedback those decisions were made to create stamps. I agree src was off the cuff, but they were viewed (perhaps incorrectly) as a seemingly meaningless size irt to the small json strings.

Honestly i'd rather come up with creative ways to make valid stamps immune to the required xcp burn - perhaps through a routine xcp burn or some other creative method that keeps them flowing without these requirement. in those cases we have mentioned a retroactive burn could be feasible as well.

This will allow them to stay part of a larger CP ecosystem, and allow us to finalize src-20 plans outside of CP in a more timely fashion. Also while allowing us to focus more on contributing to the CP codebase and db design overall. stamps are at risk here which is the major focus for artists and all that want to be involved in both ecosystems in a cohesive way.

i have no issue with stamps

seriously

the fact is you created a token layer on top of a token layer

stamps are the major component of what is at stake here.

then be part of the conversation rather than fighting and ignoring the suggestions of every other dev here

src-20 can exist without XCP fees via broadcasts EVEN AFTER AN UPDATE

numerics could probably remain fee free for the short term if you just stopped spamming them

i'm here chatting away attempting to come to a solution. the fact sits that we have more in place to support src outside of CP than we do to support a full blown cp infrastructure.

have you submitted PRs to optimize db usage?

that's what puts stamps at greater risk of having full trading (dispenser, etc) support.

stamps will be fine, they wont stop existing

any added fee would activate at a certain block

they arent at risk, you can still issue them

been busy scrambling to create src things to pull them out. but i have been playing directly on the database and mirroring it into clusters to see what works. like pulling out the unlocked (changeable fields into a new table) to allow for caching on unchangable records

XCP as a more liquid token helps everyone because the dex is way more forgiving than dispensers

its what spurred rare pepe trading in the first place

Not sure how you spent $1200 getting $500 in XCP.

Emit 1 can emit 100 for the same tx cost

with greater user complications, expensive small individual purchases of xcp and deterioration of the entire meme from the start which was free from additional token costs. in that case it is more beneficial to create our own CP systems outside of the current public infrastructure.

That AWS bill gonna SKYROCKET with the hardware apologizing for badly written software.

numerics could probably remain fee free for the short term if you just stopped spamming them

i mean we gave you the solution weeks ago

everyone wins

you said "we dont care, we want the revenue stream"

i said "you can still have that"

and you said "its too hard"

and i said "no its not"

and now here we are

jdog wrote a spec AND and indexer for you

like what more can we do?

ive offered to help, answered all your questions

you're still here in the chat, no one has booted you

realistically it's not up to us. we aren't spamming them directly. users are creating them. granted we are (and other services) are allowing them to be created, but us shutting it down doesn't help solve the bigger issues at play for stamps overall.

and yes, we don't care to shut down completely just on a whim for several thousand relatively small records.

The spec that was written wasn't in line with our json standards for one, and included all kinds of additional fluff we didn't want to implement. it was completely way off base of what we were asking for. so we decided to spend the time to develop that outside of CP altogether to prevent any future risk.

but did it demonstrate how to create assets via broadcast?

im not interested in rehashing things, everyone here got to watch it play out, but part of being in an open source project is working WITH other developers toward a cohesive vision

you've indicated you want to do that, but then your actions tell another story

its very confusing tbh

like i can tell you dont want to be the lead maintainer of your fork and manage it in perpetuity

but thats where your actions are leading you

sure, that gave us ideas and insight in how to implement. it wasn't a waste. I agree completely. as mentioned i'd rather support the current ecosystem rather than creating a separate animal ofc. how have we acted in any other way? simply by not wanting to shut down completely? to us that was an unreasonable ask (even though we did comply for several days)

is there a path where numerics dont have an XCP fee? possibly, but you need to engage in good faith

you can take the exact data you're putting in an asset description and add a transfer address to it and throw it in a broadcast

its not rocket science

thats like 2-3 days max

maybe 3-4 hours of work total

its been like 4 weeks now

That shows a lack of good faith imo

we have offered potential for retroactive keyburn, or other creative methods. only to be met with threats and resistance. not once have we said that src-20 needs or should live in the current technique in perpetuity.

The transfer needs to come from a wallet that owns the tokens. therefore we need to construct the transaction for the user and have them sign. Not an ideal solution which would require our own wallet to construct properly without users blindly signing transactions. If we are going to create a wallet we might as well create a solution for them completely outside of CP was the thought process. Of which we have been working on and have been grateful for your support in answering some of those questions via dm. I'm not sure what is in question here.

Your ignoring literally everything I just said

The Tx you create with your stamping service can be 100% replaced with a broadcast type and perform the same exact function

To the user nothing would be different

It is the path you can choose that results in everyone winning

Imagine how happy everyone would be if we came to an understanding and worked together

It’s really up to you

what part was ignored? the current broadcast methods proposed are not ideal. based on prior conversations it is my understanding that a broadcast cannot be assigned (issuer/owner) to a third party. thus it requires a user copy/pasting a message to sign. hence requiring a wallet to make this seamless no matter what way we slice it

What?

There’s a misunderstanding here obvi

There isn’t anything you’re doing now that can’t be accomplished with broadcasts

so if we are gonig to create a wallet then we might as well move all src-20 stuff outside of CP. And then only stamps remain, hampered by a xcp burn which complicates things and pushes us into a potential fork scenario

Jfc

It’s like we’re just talking past each other

“it is my understanding that a broadcast cannot be assigned (issuer/owner) to a third party.“

This is incorrect

I literally just explained how you could above

you can take the exact data you're putting in an asset description and add a transfer address to it and throw it in a broadcast

Collaboration tho: hey @jdogresorg @hodlencoinfield can you see a hook being written into wallets that would initiate a signature request?

already written... sec

https://freewallet.io/uri-schemes.html

I was illustrating a point

Discussion and collaboration means solutions to hurdles

Exactly

Love that it’s already addressed.

Also @reinamora_137 please appreciate the fact that you were able to bootstrap your entire ecosystem on the work of the devs in this chat

And we still want to help you

I am against an imminent fork. Some issues need to be sorted out (not src related).
Heading to bed now, will open github issues in the morning.

We all are, we want to work this out amicably

A contentious fork is just a headache for everyone

As a business owner I absolutely hate when a technology or a vendor or whatever it might be appears to dictate what or how I build. That’s not a fun feeling. Especially when I don’t agree with the rational.

That being said, I don’t live in a vacuum. I chose to drop everything and build in support for ordinals and all that followed, I felt very jaded. But I build a product that other people use, the technologies I use and my users are all my “clients”

Collaboration is hard, especially with hard feelings. But it is what it is.

@reinamora_137 I appreciate how hard it is to navigate this scenario. But be very careful with gaslighting. You pretty much dug your feet into the ground and said (I paraphrase) I don’t agree there there is a problem so I don’t want to do what you suggest. Pretending otherwise is gaslighting. If you don’t want to use BTNS that’s cool, just say that. It’s okay.

But the back and forth is tiring. And makes noise no one needs. There doesn’t need to be a fight.

Also you could make your own life much easier by not taking all the responsibility of maintaining all of your own infrastructure

So much productive energy wasted on this

I can commit to spending as much time as necessary on porting src-20 to broadcasts without sacrificing any functionality

Impressive

I’d rather spend time coding than arguing

We could also work on integrating bridges between src-20 and xcp assets, the sky really is the limit

That was the whole point of ordinal envelopes

bridgeburning ftw... lol

I love that term

Rgb guy found a winner with that one

Imagine the narrative if we can clean this all up and actually continue building together.

Could be a great arc

Counterparty as the mega indexer

indexparty? 😛

Incorporate ord too

Just “party”

Like HBO max became just max only it’s a good idea

All wallets can make keyburn available as an option for everyone to use, it's just using the CP API 'dust_return_pubkey' option on the create_issuance command.

Dust return pubkey was designed to be used when using Counterparty multisig data encoding outputs whilst spending from a p2sh input as there is no pubkey it can simply assume ... specifying 'dust return pubkey' works when spending p2pkh inputs too

Making that available to all makes things simpler

All these cool toys needs to be in as many hands as possible I know it is work for JDog but its a very accessible Tweak to freewallet

sounds like a Mega corp rebrand!

It’s good

Partyd as the daemon

Partydown

Dust return pubkey should also be a parameter with create broadcast

yeah it is

I not used it but I a sure it's shared

I would imagine it’s available for all txs

can be set at server level too

I think this is the main thing we have not gotten clear even though it has been stated that a solution has been presented:

###create_broadcast

create_broadcast(source, fee_fraction, text, timestamp, value)

does not contain the transfer_destination

```
create_issuance(source, asset, quantity, divisible, description, transfer_destination=null, lock, reset)
```

perhaps i missed some detail here, but we need the the transfer_destination (for mints and deploys primarily) and of course the already supported advanced parameters for keyburn. the divisible, lock, etc are moot points ofc. The transfer_destination (for mints) has been the sticking point, and yes maybe i'm not seeing clearly the proposed solution to this? This has put us on a path of just moving to our own wallet for these, along with other threats and degraded overall support for stamps overall which is of mutual "blame" and nothing to hold up potential for getting past the impasse.

There are several issues at play here depending if we are talking about an src transfer vs mint/deploy.

And yes, this new information from the url-schemes (unknown until now) is not a bad (closer to anyway) solution either counterparty:?action=broadcast&message=Some%20Message. --- this does not support the keyburn however, and the timestamp field is a bit confusing.

Overall it has been confusing with the btns stuff which is not in line with our specs at all (albeit maybe better in some ways), and instantly created a "competitor" which is ok overall, but it puts us in a tricky spot and forces decisions that may not be for the greater good while we are just trying to create something for fun and see where it can take everyone.

Basically we have the perceived threat of btns, delisting of banner on xchain, public threats against stamps, removal of particular tokens, threats of removal of all numeric assets from xchain, etc. All of this puts us on the defensive which is not conducive to working together to find solutions that benefit the community. I'm sure it's not complicated for us to even implement a PR for the transfer_functionality, but previously it didn't seem worh investigating because of the perceived threats to the entire stamps ecosystem. Asking to shut down completely is not a solution. /vvvv

"competitor"... heh... I didn't promote it, I haven't told anyone to mint, I haven't put out anything but a spec.... but yeah, I DO plan to build out BTNS now, regardless of what you do.... it is a fun way to play around with a BUNCH of features that CP has, and mix in testing of those features way faster.... but... NOT pitching it as some solution to anything other than fucking around with tokens... so dunno why your so threatened by it.

but I digress... I want us all on same page and to work together... if possible.

Asking for a pause on the minting was about establishing a mutual respect as much as anything.

"competitor" was in quotes for that reason. src-20 is the same type of animal for us. an experiment.

so... can you get on board with PAUSING src-20 minting and letting joe work on your codebase to pivot src-20 to broadcasts..... or. do you want to go the fork route?

all cp txs with multisig encoded data outputs, which can be forced ..but broadcast uses by default

i don't see why it has to be either or. we are going to pivot src-20 regardless of fork or not. they are completely separate decisions. the fork is only for stamps as far as i'm concerned to keep them outside of the proposed xcp fee and potential burden for creators (mostly based on threats to the stamps community overall) - however as mentioned we are ok with some sort of overall fee structure or something that gives back to xcp without the per transaction burden. Perhaps pre-registering millions of assets prior would be a solution, but the re-issuance fee slightly complicates this as well (even though far cheaper)

src-20 would be separate from any fork regardless. going back to revisit the broadcast technique is one that we will take into consideration and not out of the question. the minting has slowed down considerably anyway so the current growth rate doesn't really necessitate a complete shutdown imo (and there are several providers deploying these transactions on their own services which we cannot control). changing what we scan for as 'valid' would thwart these given a change in either direction.

That’s a lot of words to say no

If you were truly concerned about "stamps" you could easily pause src-20 minting.... so, your making a decision here.

agreed. we have heard that this will be supported, and then later that it would not. so we felt forced to make our own wallet, etc.

@hodlencoinfield You want to have some time to provide some rails for src-20 ppl to transfer tokens on their own to the broadcast system? (ie, hostile takeover of src-20 to "save" stamps from having numeric fee).... or, do we push out fee on numerics now.... IMO this guy not gonna play ball.

I’m floored. All this, offered collaboration, agreement to go “water under the bridge” and still not budging, I’m out of this conversation. I feel ashamed for you. Your ego is going to destroy this opportunity you have.

a custom wallet like rarepepewallet is would allow you to craft broadcast transactions for your users in their own wallets

My platform will support whatever direction your infrastructure ends up going as long as there is demand for it. But I’m still in awe

yeah this is a good solution as well.

not sure what you mean. still here open to the conversation on whatever may happen. laying out the though process and challenges we have run up against

No one is your enemy here, everyone is trying to help and find solution which is good for all, be smart when there is still time

This this this is gaslighting. You said NO. To pretend otherwise is bullshit

Now I’m feeling frustrated. I don’t like psychological games

what does shutting it down do for anyone? Save maybe a few hundred or a thousand assets, meanwhile other services continue creating them?

I agree.. this is another opportunity to look again at working together. Other groups are already pushing their own methods and they won't be stopped but we are still move towards a solution at the same time

It establishes a mutual respect and a goal of working together

javascript for the wallet and some php for the extra magic on the back, end .. you czn get funky server side with it and could even link to python scripts on flask ...

crafting/creating the transactions for the users is done over the api ..signing of the tx is then browser based javascript

you get full control of the user experience and the user gets all the abilities they need and can't mess it up .. well hold on maybe not perfect but ticks all the boxes

Your entire payload is in text parameter

No one “owns” a broadcast in Counterparty, they simply create them

yeah so to transfer a src20 it just needs to come from the holder

We should rename the merry go around to Reinamora

Perhaps that is the perceived problem here.

I’m not a xcp dev so don’t shoot my if what I say here is dumb:

Does adding a utxo to the broadcast for dust to a specific address solve this problem @reinamora_137? This way you have a hard coded destination? In the tx?

It seems like the problem is not having the recipient as part of the utxo structure?

But like I said, I’m new here

if user makes a tx ( using a custom wallet) and broadcasts a multisig output paying the change to themselves then only broadcasts from those with a balance are valid

it's the indexer job tracing Balances.. your wallet wouldn't even allow a user to make such a broadcast

so you web wallet gets data from indexer and shows to user

user can deploy mint send receive all via broadcast msg

they have own keys, they make transactions exactly as you code them to be

It’s not a problem, the src20 tokens aren’t recognized by Counterparty either

the wallet only needs to use broadcast .. no xcp no assets ..just bitcoin and multisig outputs

xcp counterparty multisig data encoding to utxo but not xcp token

use counterparty seeds and is 100% compatible with everyone's stamps made with freewallet too

Thank you Bob

so tracker is a mysql database.. website wallet then uses counterparty api to crate txs that are mined in block chain.. index updates updates wallet.. all counterparty ever sees is a broadcast msg

welcome

The broadcasts are the clear text ordered txs that any json esque token layer can be built on

Counterparty does all the heavy lifting

I could envision a system where there are different broadcast types that can be disabled or enabled in the node config

custom wallets are where its at for creating user experiences

the multisig encoding with keyburn gives you utxoset residence .. what you do with that is abstracted up

Could even expand on that and use the 3rd key for data

Update Counterparty to parse key if it doesn’t match sender

yeah if its not spendable but used it gets more data for each satoshi spent

ahh to skip it for validation ..yeah nice

ah even on the in after it's mined as well as the out when constructing tx

Yep exactly

and if you do that stamps get 30% cheaper

Yep

so multisig p2sh inputs would still be able to function normally when using multisig encodiny outputs and pass a dust return pub key as there is no sender pubkey to check against ..so fully backwards compatible cip

Yeah it would still need to have an activation block tho