- 15 May 2023 (515 messages)
-
anyway... AFK for a few hours.. no desire to argue... burned out... just need community to find line so I have them behind me if/when we need to push
-
-
If community can not find this line, I will fork CP repo, put out my OWN release (counterparty-jdog), move xchain to it, and then we are in even stickier situation..
-
Find the line... please.
-
-
-
what is it you want to do? add the anti-spam fee on numerics?
-
i dont think anyone in here has disagreed with that in principle
-
I do not want to add anti-spam fee... I do NOT want to fork... I want COMMUNITY to sus out the line hey are comfortable with... so it is clear to @reinamora_137 where that line is, and that CP WILL put out a fork and fee on numerics when that line is crossed.... For me that line is 15K which is RAPIDLY approaching.... but ideally just need consensus on the number... without consensus on the number, I have to do shit on my own, which is NOT what I want to do
-
20k
-
i dont like this "whats the line" thing, i think we need to make a decision based on counterparty sustainability, then set a block to update
-
yeah, we need fee on numerics, I agree.... just dont feel we need to force it now to stop creativity on stamps.... just want to stop spamming and let src-20.1 transition to broadcast system.... once they are transitioned, THEN we can talk about putting fee on numerics
-
because their are ppl out there who don’t know what’s going on and don’t know they are part of a spam flood….
-
fee on numerics needs to be discussed more... and I feel 0.25 is too high.... dont want fee now, but might have to enforce now... so just looking for your #... sull is 15k.. I am 15k.. you?
-
That’s very fair
-
you can't force anything even with the fee is what im saying, because they just load up on xcp and keep doing the same thing
-
charge a little extra for each mint to cover xcp cost
-
yes... all the more reason for stamps team to come out against src-20.... as I suggested yesterday.... they ARE acting in good faith, they HAVE pausd service... they ARE playing ball it seems... just gotta put out message to community to stop src-20 spamming.... OR, have us sus out where that line is
-
even if stamps btc only thing ended because of xcp fee decisions, then that whole stamp collection freezes and is akin to rarepepe when it stopped. not end of world. prob makes them more valuable.
-
gotta write BTNS indexer n get starbucks... closing telegram (only way I can work)... back i 2 hours
-
Until the price of XCP is too high and no one will do it
-
focus needs to be on counterparty itself and what changes help to keep it sustainable, projects come and go, you shouldnt make changes because one person is doing one thing you dont like
-
in the hypothetical distant future
-
Got ya... hence the 0.25 XCP fee to match subassets... no discount... following
-
yeah i think thats fair and inline with what we're already doing (ie subassets)
-
but dont think it will stop anyone from spamming assets even with that fee
-
what do YOU want to do now? put out a fork to disable numerics? wait and see if we cross a line?
-
gotta go, but arbitrary # since you’re seeking it… src-20k hard stop or gtfo
-
Sounds like the fee upgrade shouldn’t be conditional on amount of mints, should just be a yes or no, and then a block# it goes live…
-
exactly
-
Sounds like the fee question is a resounding yes, and an obvious simple first step
-
yes agreed
-
so lets set a block height
-
then you can announce on counterparty twitter so it doesnt catch people offguard when it happens
-
-
maybe a week?
-
PR is done
-
i put 789856 as the block_index for the protocol_change, that should be around 12 pm GMT (right now is 12:57 am GMT)
-
but, you can change that in the protocol change file, of course
-
i think a couple hour notice is irresponsible
-
Def
-
a couple days at minimum
-
I agree
-
preferably a week
-
just forwarding what javier sent... agree more time is needed... you guys pick activation block please 🙂
-
is anyone aware of any other services using numerics besides stamps?
-
Feel like this would be too much time... very few nodes... only concern would be exchange updating... and they only deal with XCP, not numerics, so this change wouldnt effect them immediately
-
it would if someone issues a numeric on old node and trades it for xcp
-
balances would be off
-
i dont think a week is too much time tbh, this is going to be an ongoing issue
-
ok. I am fine with deferring to your opinion.... please tell me the activation block for 1 week and i'll get the PR updated and put out a release today
-
like i said, if its economicly viable for src-20 guys to load up on xcp and keep minting with the fee you're going to see the same thing keep happening
-
i mean 0.25XCP is what like $2?
-
so this doesnt really solve the issue then... issue is spamming unusable numerics
-
thats nothing in the grand scheme of things
-
so get rid of numerics and they spam the namespace with 0.5 xcp fee
-
if they continue spamming unusable numerics, we have same issue... YAY, they pay some XCP... btu BOOO... they still slow down xchain, freewallet, and grind CP ecosystem to a halt
-
at least they would "revisit" the code and hopefully not spam issuances for every MINT and TRANSFER
-
-
"hopefully"
-
issuing ONE unusable asset ONE time is fine.... not ideal, but fine.... spamming unusable assets fore very action is where the damage is done
-
that was @reinamora_137 second suggestion
-
especially now DexTrade is holding XCP deposits hostage without explanation, and no withdrawals
-
So, this fee on numerics doesnt REALLY solve the issue.... if they continue spamming src-20 and just pickup a bag of XCP... we have same issue
-
the solution is to work together
-
it always has been
-
Dex only holds 32,000
-
will re-read... as I understood #2 it was just get XCP and keep spamming MINT/TRANFER for numerics which is the problem
-
-
This will slow things down while a protocol upgrade can happen. Stamping services will need to account for fee
-
no #2 was issue a single asset and just keep changing the description
-
which is probably fine
-
then phase out this method and phase in broadcasts
-
I'd agree with that much... seems a shame to lose a free asset minting option, but I can see the problem needs a resolution... 0.25 XCP is at least somewhat of a disincentive
-
it was never a problem until people started using assets as arbitrary data stores
-
will re-read... as I understood #2 it was just get XCP and keep spamming MINT/TRANFER which is the problem.... buying XCP doesn't solve this bad behavior.... teamwork and cooperation is the ONLY way forward.
-
but you could use a named asset as an arbitrary data store
-
if these assets where being made to be used as assets, that would be fair use, but they're being used for data storage as I understood it, which is not the intended usage
-
yes, that's not fair play
-
especially because they're minting on behalf of other people
-
cool.... price of XCP can be $1 million per coin... who cares if you can't load a wallet and move rare pepe?
-
But this is exactly what we argue on Bitcoin. It’s a market
-
-
we need to rethink the db tables and queries to be able to filter the non-assets
-
no, complaining that a current service is degrading the platform for everyone else
-
CP DB need a rework anyway... it doesn't index addresses, transactions, assets.... al that data is written thousands of times again and again in the CP db... lots of optimizations to be made for sure..... just trying to keep things running to buy us time to optimize 🙂
-
-
all the txs are valid counterparty txs .like all counterparty txs are valid bitcoin txs
-
CP is an asset trading protocol, not a free data storage service
-
all this is to say... BUILD MORE EXPLORERS... lol... if there was another explorer right now... they could say "J-Dog is just freaking out, we will have our API work fine".... multiple voices... but since CP community has deferred all infrastructure to me (through lazyness), I am only one running an explorer.... and the way my explorer is written, this unusable asset spamming is an issue 🙂
-
high fees are a product of demand, stamps are in fact degrading bitcoin tho by using op_checkmultisig and a burn address
-
-
FYI...anyone who wants to "dig into" the xchain backend.... it is all powered by this tool which moves data from CP sqlite database into Mysql indexed database
-
GitHub - jdogresorg/counterparty2mysql: PHP script that populates a MySQL database with Counterparty data
PHP script that populates a MySQL database with Counterparty data - jdogresorg/counterparty2mysql
-
so bitcoin devs will need a way at some point to reduce the utxo set, either by filtering out "unspendable" utxos or using some type of accumulator
-
just splitting out named and numerics into different asset tables might be a good first step
-
Or price them out.
It’s funny that XCP is a shitcoin that is directly going to help Bitcoin price them out. -
they'll be priced out once this wave peters out
-
Quick Numeric Fee activation block calculation
---
1 block x 10 minutes x 60 minutes * 24 hours = 144 blocks per day
144 blocks x 7 days = 1008 Blocks
Current block index = 789,864
Numeric Fee Actiation Block = 790,872
We will activate fee on numerics on block #790,872 -
We have our activation block.... Joe, can you wrote up the announcement of the numeric fee and activaction block however you would like it communicated via twitter? I will tweet it out.... just too busy to write up the text myself now... gotta focus on some dev updates now
-
-
The fee on numerics might not stop the behavior but it will slow it down and prove who really wants to be players in the game.
Also to consider is that this is definitely just a fad that will indeed blow over at some point. But until then, I'm all for initiating a spam disincentive in this particular manner. Just my 2 bits. -
lets run a poll in here for a few hours
-
ill create one, gimme a minute
-
XCP Fee for Numeric Assets?
59 vote(s).- 35.59322033898305%, 21 votes
- 23.728813559322035%, 14 votes
- 11.864406779661017%, 7 votes
- 28.8135593220339%, 17 votes
-
will keep this up for 2 hours then we'll have a good idea where the counterparty dev community stands and consensus to move forward
-
if you vote for "continue discussion" please layout what you think that should look like
-
We've had XCP support for a while in our mobile app WLT. It's a multichain NFT-centric wallet, view-only plus basic transactional wallet on Ethereum and Tezos. Adding Ordinals support soon, too.
https://WLT.satoshiscloset.comWLT by Satoshi's ClosetWLT v0 available now.
-
Amazing news! Thanks for sharing! Any eta on being able to sign cp txs in your wallet? (They are normal btc txs… and can be generated via api.counterparty.io … FYI, you don’t even need to run a node to add send support😀)
-
Lmk if I can help in any way👍🏻
-
there’s a lot to be discussed I think. From relaxing numeric fee after the storm, removing numerics except for subassets, database optimizations so this ise case issue wouldn’t be as detrimental as it is, the idea of ephemeral assets that are purged from db after primary utility/action is complete (archive snapshots etc), and most importantly, should CP even support and encourage meta token layers even if done efficiently?
-
there’s also a proposed CP file system CIP…. could be used for db dumps for static archives so to purge and clean the main db for performance gains.
-
Imo, CP since 2014 has been a UNIQUE asset name platform. This is being blown to pieces now. I understand that names are squatted and unused for years (unusable in similar way as the current numeric spam) but that’s what forking solves if it’s that important. I’m not in favor of layering on new names token protocols especially when it doesn’t even exclude the already minted names. Like WTF?
-
select count(*), sum(length(description)) from issuances where description like 'stamp:eyJwIjogInNyYy0yMC%';
11146|1010466
strange i get a lower count than you had yesterday on that query (at 11157)? Any insight as to why? I do see a ton of missing trx on my nodes around block 789316 (but waiting on a re-index). Interesting the db size i s only 7.9 GB - super compact considering all the spamming -
mysql> select count(*), sum(length(description)) from issuances where description like 'stamp:%';
+----------+--------------------------+
| count(*) | sum(length(description)) |
+----------+--------------------------+
| 45914 | 13539292 |
+----------+--------------------------+
1 row in set (0.34 sec)
mysql> select count(*), sum(length(description)) from issuances where description like 'stamp:eyJwIjogInNyYy0yMC%';
+----------+--------------------------+
| count(*) | sum(length(description)) |
+----------+--------------------------+
| 11157 | 1011512 |
+----------+--------------------------+
1 row in set (0.34 sec) -
Not sure why your seeing different numbers... I am running my query against XCHain database... sec let me run in sqlite (CP database)
-
select count(*), sum(length(description)) from issuances where description like 'stamp:%';
45808|13511930 -
sqlite> select count(*), sum(length(description)) from issuances where description like 'stamp:eyJwIjogInNyYy0yMC%';
11146|1010466
sqlite> select count(*), sum(length(description)) from issuances where description like 'stamp:%';
45808|13511930 -
ok cool we match on that side
-
is the poor design in SQL or in the CP DB? it does seem quite tiny considering
-
would say "less than optimal" design is in CP (it works, but doesn't store data efficently).... counterparty2mysql pulls data out of CP sqlite database and builds out indexes for every address, transaction, asset... so we can reference an integer rather than some text string.... integer indexs are way faster than full text query matches
-
counterpary2myql populates some additional tables that CP does not.... to make things faster to query, easier to index, etc
-
GitHub - jdogresorg/counterparty2mysql: PHP script that populates a MySQL database with Counterparty data
PHP script that populates a MySQL database with Counterparty data - jdogresorg/counterparty2mysql
-
specifically the "Additional Tables" section... those are xchain specific indexs and tables.... ideally, want to get those indexes back into sqlite database... and possibly move from sqlite to mariadb or mysql... but, database optimization for CP is an issue that needs dealt with, but not immediately.... right now main focus is keeping current infrastructure up 🙂
-
bitcoin stamps - forked because of a 7.9GB database lolz. at least we are nearing a consensus and can make plans to move forward and get back to these upgrades on src-20.1. Thanks guys. I appreciate the open discussion and insight.
-
None
-
Let’s keep this poll going for the rest of the day so people in different timezones have a chance to see it
-
Counterparty should adopt and implement this minting method feature for new assets. That should be possible, right?
-
That would eliminate most of the demand for the num asset storage method
-
That’s def an option too although it would probly need a new issuance type and require time for writing and testing
-
I think a big potential issue going forward with this 2nd layer token stuff is confusion over multiple types of tokens that don’t interact with each other
-
Big value prop of Counterparty is all tokens are interoperable
-
So integrating into current assets is ideal
-
Yeah, it wouldn’t be very good if it had to be a new token type
-
Yeah which is why your suggestion makes most sense it just takes longer to integrate
-
There is clear market demand for it currently, and it’s the only rationale I can see for brc/src being so popular
-
I faded Ordi and missed out on those sweet gains which caused me to FOMO some SRCs
-
How is the xcp burn done via the api? I assume if we do fork and don’t do the burn they would show invalid on xchain but not on our explorer?
-
-
For clarity. Regular stamps which do xcp burn will still continue to be valid xchain assets? Or is that still an eminent threat as these grow? There are currently pending drops of 10k assets. Given the tremendous size difference over src-20 these would be much more usage in the db. I just don’t want to run into a similar discussion in a month or two causing drastic measures on both sides.
-
-
Ok, I hope that is the consensus because that has been brought up in the past. It will cause much more drastic space usage than src-20 and potentially just as many new records. If it were me database optimization would be priority 1.
-
The threat from "STAMPS" is just that the database grows cuz your stuffing file data in there... the damage is limited right now, and we have plan to migrate that file data out of database and into filesystem... so YES, Bitcoin Stamps can continue stamping on numerics, as long as you guys pay the XCP to register the numerics... at which point, pls explore that asset naming system a bit, its much more pretty than A8490328490242... you could issue STAMPCHAIN and then STAMPCHAIN.Stamp_Artwork_Title.... since your going to be paying the same 0.25 XCP fee as subassets (subassets are just numerics with some lipstick on them).... What your really doing in the background is issuing a numeric, but now you have your fancy STAMP named asset associated with every stamp, and you establish a parent->child / asset->subasset system for your project
-
you still give ppl a numeric, they own, and can do what they want... but get some extra bonus features now that your paying 0.25 XCP... might as well take advantage of the additional features 🙂
-
excellent. Glad to hear. That will be a cool way to query for our assets as well.
-
can also do collection/series stampings...
STAMPCHAIN.FakeStamps.STAMP1
STAMPCHAIN.FakeStamps.STAMP2
STAMPCHAIN.FAKAMOTO.PIECE001
STAMPCHAIN.FAKAMOTO.PIECE300
...
etc.. you get the point 🙂 -
there is only 1 level subasset... but you can "fake" sub-sub-sub assets by just using periods and a structured naming system 🙂
-
Sure feels like i'm rebuilding counterparty consensus engine here... re-inventing the wheel again.
-
anyway.. BTNS indexer in the works... i'll make it public / open source so anyone can run... will be pretty damn easy tweak to support src-20.1 when needed 🙂
-
But why even bother is my opinion
-
should be activated at a certain block height. We wouldn't want to fuck with the historic stamp numbers by renumbering and accidently including named stamps from the past.
-
cuz this brc-20 chasing nonsense needs to play out... there is clear demand (tho I believe most is just pump n dump / goldrush mentality) to experiment... so, just trying to support the xperimention.... I think i'll just run any BTNS API from the btns.wtf site when I get it up.... so it is clear it is not a part of counterparty, and not officially supported yet.... just something ppl are experimenting with... if there is any value from this (I think there will be), then we can implement anything we need to into the CP protocol when community feels it is appropriate 🙂
-
I feel like Brc-20 is just a shitty counterparty asset and adding another naming system undermines existing named asset holders on CP.
It just seems like chasing something to make something already existing that’s worse. -
We already have STAMP Protocol, STAMP Filesystem, and lots of discussions happening on how to move CP forward... so, benefits us to let it play out on our platform.
-
What about excluding named assets from BTNS for a claim period or something? Do we really want dupes? granted I guess BTNS isn’t nec even CP but then again, it’s a CIP deployed so it is?
-
CIP does not mean a code change in counterparty, or official acceptance of a spec... it is a CIP to give guidance on how to use the system, because it uses Counterparty.... there are other specs like BVAM and STAMP Protocol which define the process for doing something on counterparty.
-
I think a CP fork is needed
-
true…. so meta
-
How would fork prevent BTNS from playing out? or anyone from using the broadcast system to build alternate systems and experiment?
-
I don’t see how BTNS improves CP. It may improve current usage pattern tho
-
The fork could be done so to make all token types compatible
-
It does not improve CP, and definitely threatens current asset system... of which I own well over 10K asset names... I get the threat... but, would prefer to continue to support experimentation on CP, and let it play out, vs forcing a fork just to try and stop people from creating alternate name systems.... they gonna do it anyway, why not have them at least aware of CP and provide rails for them to "graduate/upgrade" their BTNS fake token to a real counterparty asset... which then can use all the benefits of CP.
-
-
and type namespaced to avoid collision. JDOG.XCP <—> JDOG.BTNS
-
to be clear... I do not want to build out some alternate namespace system... its not like I am rah rah lets do this and think this is some new great system
-
I understand your position
-
it is fucking retarded.... but, science is messy, and I am already seeing value come from more focus on Bitcoin and CP dev.
-
but again, I am just one voice
-
Just feel the need to point how how fucked up this is too
-
agreed, and I appreciate your outrage.... we need as many voices and opinions as possible.
-
Doesn’t effect me tbh, just broadly speaking, this is all laughable
-
offering some ideas along the way :)
-
-
-
BTNS will probably end up replacing legacy CP from within
-
this is really 🤯
-
For this to move forward, all that would be required is for you to use BTNS, establish a new prefix xt: and declare some rules in your spec that BTNS names registered would be considered INVALID if the asset already exists in Counterparty...... announce spec, ppl will read, immediately start minting, and all the pre-existing asset names like TEST, RAREPEPE, OLGA will be preserved.... it is a way to respect the XCP system... it is how I would have liked to do BTNS... but environment too hostile I think, so needed to release base system... but, feel free to make these tweaks, and announce your own system that respect XCP assets.... I could support it right along side BTNS and could show it as the "preferred" method over BTNS
-
Whatever it solves is at the detriment of CP legacy
-
which might be fine
-
this is true
-
BTNS is a spec for projects to fork and define their own rules... I just used the bt: prefix as the default... its not the standard 🙂
-
anything I say is only out of how weird it all is. Be interesting to see it play out like you said. I’m not outraged just like WTF lol
-
-
Coolest things come from huge WTF’s sometimes
-
don’t we know it
-
meanwhile i’ve involved myself in helping to steer BRC-20 despite having no interest in doing so really. I get it ;)
-
which makes me wonder…. a way to make BTNS commingle with BRC-20 🤔
-
I still plan to move forward with a VM... write code in javascript, compile to bytecode... logic on top of CP hardcoded rails.... was supposed to be a couple months into it by now... but, Stamps 😛 ... anyway... just saying, just cuz ppl bringing ETH and EVM to BTC... we still gonna stand apart, roll our own VM (tho first on dogeparty)... so, we still got tricks n enhancements to make... CP has always, and will always exist... we are the swiss army knife of bitcoin 🙂
-
Have you been watching miniscript?
-
-
-
heard about it few times, thanks for link
-
How is the DB impact of a new-asset-issuance vs an update-issuance?
The fork will make it expensive to spam by issuing new assets but you will still be able to make infinite updates to an existing asset without paying xcp fees. -
Yep exactly, no matter what more Counterparty usage means bigger db
-
Too soon to place wagers on upcoming sizes from the current 7.9gb? haha. Maybe we can activate the betting functions and really step up the degen game! Dare we wager on src-20 price action ? 🙂
-
well... we won't add taproot support until we get our arms around the "files in database" issue.. so, yes, DB is growing, but it is a short-term issue, which we have a plan for... so, damage is mitigated for now... but we should def have discussions on limitations to put on various fields (like asset description).... but all this is fine, can be dealt with pretty easily 🙂
-
I've been meaning to build a betting interface for a while... even wrote and ran a sports betting site... slurped up all sorts of feeds, provided them for XCP... but ran it anon, so never got much traction
-
TLDR... if you wanto work on betting, I am supportive, and happy to share code to let you stand up thousands of oracles / things to bet on almost immediately
-
🙂
-
-
Not a watch wallet for much longer @hodlencoinfield https://twitter.com/hirowallet/status/1658214008447729664?s=46&t=h1IrRMWKX4jvwsMxM_AqDQLink
📤 Support for sending your Stamps & full support for SRC-20 will be coming in a future update! 🔒 In the meantime, we’ve already added safeguards to prevent accidental spending of Stamps & SRC-20 tokens. You can track progress here: https://t.co/KnNZDw16K8
-
Nice!
- 16 May 2023 (97 messages)
-
been a long time coming.... dormant for so long.
-
POLL RESULTS
XCP Fee on Numerics?
---
55% = Yes, 0.25 XCP
16% = Yes, 0.5 XCP
10% = Yes, Discuss
19% = No
XCP Fee on Numerics (YES/NO)
---
81% = YES
19% = No
What Should Fee Be?
---
55% = 0.25 XCP
16% = 0.50 XCP
10% = OTHER
Activation Block
---
790,000 = Current block
+ 1008 = 144 blocks per day x 7 days
---
791,008 = Activation Block
It appears that general consensus is to institute an 0.25 XCP Fee on Numerics at block 791,008.
@hodlencoinfield Agreed? -
Almost done with BTNS indexer, then can focus on CP 9.60.2 release which will include:
- Mempool parsing fix
- Insufficient BTC Balance fix -
so i’ve been thinking about it and im not sure its a good idea to add the xcp fee at this point, it doesnt really solve anything and it just creates a barrier to counterparty being integrated with ordinals and other bitcoin indexers
-
if it really solved something id be more inclined to support it but im more worried about a fork
-
for example, @reinamora_137 gave two course of actions for src-20 to reduce load on asset table in counterparty db, neither would require an XCP fee even if one was introduced for numeric assets
-
the thing we ALL want is for counterparty to continue functioning in the most performant way possible
-
i think thats something 100% of us would agree on
-
so if you look at it from that perspective, a numeric asset xcp fee doesnt address it at all
-
and the much bigger risk is that wallets and services integrating with stamps just decides to keep running the previous version
-
my vote is on continuing discussion for now and to not do anything in haste, and be mindful of the biggest existential risk (two competing forks)
-
So... someone is free to see how src-20 abused CP, and continue doing so... and it remains on me to pay attention to database usage, try to sus out what project is abusing things, sound the alarm, and then do all this again?
-
I am not a fan of the numeric fee being instituted in this way as well... but, it is an attack vector that needs closing, you yourself have said that
-
I dont want to be the fireman anymore.... community spoke that they want a fee, now your switching positions?
-
I just want a decision oe way or the other.... you forced poll... poll says fee is what ppl want.
-
im saying we should keep thinking about it
-
in the meantime???
-
poll says 70% of people IN THIS GROUP, think we should do it
-
again... not putting the fee in now puts the burden of watching the CP database back on me.... I once again have to wear yet another hat.. can't just be a dev building on the platform, have to worry about who is doing what, AND pay attention, cuz no one else is
-
ppl wouldn't even be aware src-20 was an issue if I was asleep at the wheel
-
what im saying is the fee doesnt fix things
-
the more ive thought about it the more that is apparent
-
cool.... and your ONE voice in CP
-
yep
-
The fee is basically putting some speed bumps on the highway?
-
I polled for the fee, but I see it is only a temporary mitigating measure, while the bigger challenges are worked through
-
just so everyone knows this is a poll, not a binding vote or anything
-
agreed, we have workable solution here and "attack" has stopped.... just a matter if we wait for next "attack" and is it fair to put that burden on one person... I want to focus on dev, not watching CP all the time for who is going to break it... no one else is watching, so it is yet another thing that falls on my shoulders to sound the alarms... it is exhausting. I want to code, not be an alarmist and have to cause drama.
-
this does bring up what I’ve been hinting at, a documented way to formalize this part. I know there used to be a foundation, and a way to propose votes and a voting process,… where does it all stand now?
-
-
I get that….
-
we are one tweet away from having the centralized topic going wide. we should address this by having a process.
-
Counterparty Foundation never voted on code changes…. They have no say over tech details… just general guidance and approving budget/funds requests…. Same with current Dogeparty foundation…
Our process here is to discuss things, and we don’t push out contentious changes…
I agree that finding “consensus” is tough, same issue in BTC dev…
We don’t push contentious code changes unless it is absolutely necessary (to stop attack or fix show-stopping issue)….
Pushing contentious code often results in a controversial fork and unnecessary drama…. Had drama over the years, but managed to stave off any serious fork attempts so far. -
Clearly community still conflicted over XCP fee on numerics…. The spamming src-20 issuances has stopped, the need to force this change now is no longer present. We have code to “fix” any abuse if it happens in the future.
I think the best approach at this time is to continue with discussions on when to implement a fee on numerics, and what that fee should be….
Will put out release later today, it will NOT include the fee on numerics at this point. -
Maybe we should have a board of coders (maybe CIPs or something determines eligibility) of some sort the community elects to determine what updates get pushed.
-
I agree with this, it will be a terrible look
-
Okay, so the ability to implement the 0.25 fee on numerics at short notice, with a gentlemen's agreement on cessation of the usage of asset for non-asset data storage purposes, is where things stand now?
have you published a change list for what's being pushed in the release later today @jdogresorg ? -
I know stake holders will want to be able to influence things, and if it’s formalized, it’s like a protocol…. no arguments, just follow these steps, etc…. I know that’s easier said than done. I know dev by committee is impossible too, it just feels like a shaky house of cards if we aren’t prepared to address this
-
anyway I’ll shelve this discussion for later, don’t need to muddy the waters by trying to solve more than one thing at a time
-
yup... and the main reason why all the dev chatter on this src-20/fork drama has happened HERE and in STAMPS dev... and NOT in public forums... I went out of my way this week, even while I was extremely frustrated with minimal communication and understanding from stamps dev team, to AVOID having this drama play out in public forums... We are all devs, and just needed communication and get on the same page.
-
NOPE! IMO votes on code is not the way... votes are easy to game... consensus is the way forward, even if it is hard, all good things are hard...
I DO NOT want to participate in a project where non-technical people have ANY say over what technical features/fixes get pushed... Leave the tech stuff to tech guys who understand it to push code.... Communities job is to discuss ideas and issues and make it clear their intentions/desires... Coders job is to figure out how to implement communities wishes in a technical way... We want more devs on CP... but we DO NOT want more noobs saying "hey, have you tried doing X" and suggesting features to devs that have already been tried... ALL approaches should be discussed, but, IMO devs time is wasted having non-technical conversations again and again trying to relate "code-level logic" and "been there, tried that logic" to normies. At the end of the day, it really comes down to a few people making the call for what is "right" for the community... yes we listen to the community, but you guys defer to us tech ppl for a reason... 🙂 -
Final thoughts before going AFK for a few hours:
NOTHING is gained by making SRC-20/devs look bad (It was a rushed spec implemented with no consultation with any CP devs, it happens, best to fix real issue "abuse" and move past it)
NOTHING is gained by CP putting a fee on Numerics before we absolutely have to (it stops ppl from being able to use CP without the "XCP Shitcoin")
PROGRESS has been made this week, Stamp/SRC DEVS and CP DEVs now talking, and working on solutions together 🎉
PROGRESS has been made on CP dev because of all this new attention in the past couple months (Bitcoin Stamps, STAMPS Protocol, STAMP Filesystem, p2wsh Encoding, Taproot address support, Broadcast Token Naming System, BTNS/SRC Indexers, etc)
TEAMWORK makes the DREAM work.... LFG 🚀🚀🚀 -
-
-
-
I’ll take the blame for even bringing up numeric xcp fee as a potential solution.
I believe cooler heads have prevailed and we can all keep moving forward to help ensure Counterparty nodes run as smooth and efficient as possible while keeping Counterparty in the conversation in regard to token layers on bitcoin. This is something I think we all can agree on. -
<Luke Dash Jr MODE DISENGAGED> 😛
-
Lol
-
"Thou shalt only broadcast bible verses on Counterparty" - J-Dog Dash Jr 😛
-
i’m against numeric fee, but chose the more discussion poll option.
numerics were added to be free alternative to reserving unique names. subassets were created as a cheaper named asset under parent assets.
i lean towards either pausing numeric usage when abuse (attack) is discovered that harms the infra (after discussion and voting ideally) or possibly enforcing an XCP staking scheme that in order to make a numeric you need to hold some amount of xcp at that address.
or remove numerics entirely and let broadcast method be used for btc only use cases. -
realistically, does it really matter if the CP node is a little slower since all of the major users in question here are both exporting the CP data into separate databases for public consumption (aka us and J-dog).
The public facing data store is the one that needs to be robust to handle massive loads and handle caching, etc. . CP is just an indexer at that point.
We are talking about 7.9GB here not petabytes -
most of the data is not changing anyway, and we see sub 10ms response times on many of our api calls... so even 100x the database size wouldn't be an issue
-
-
unless this whole operation is running out of the closet on some spinning rust from 10 years ago on a dsl line it's really hard to believe some text strings in a database is even being called an attack. that's the bottom line really. there must be something else deeper going going on here. There are billions of numeric assets available for a reason, why not use them.
-
Yeah but as jdog pointed out there is a lot of redundant data in there too that should be cleaned up, so better data storage is something we’ll need to look at either way.
That said, we should still be thoughtful in how we add data to no create duplicate entries if at all possible. -
makes perfect sense, but it all seems to be blown way out of proportion
-
Sure but also jdog shoulders the responsibility of providing infrastructure everyone uses so he feels the stress and weight of that, understandably
-
So what we can do is take some of that weight off by building alternate block explorers, wallets, etc
-
I like the pause idea.... perhaps a hardcoded CP controlled address which can broadcast a specific "PAUSE NUMERICS" message, which would pause any numeric issuances... could immediately stop any "abuse", and could just do a "RESUME NUMERICS" message.... not a really sexy solution.... but, I think having the ability to pause/resume numerics is a very interesting idea... and it allows us to continue having conversations on when/what fee on numerics, and stop any abuse, without disabling the feature.
-
it should be seen as a good thing of forcing the issue of upgrading the database store, and bringing more eyeballs to CP. All of that brings in more dev funds and resources to scale
-
So let’s build more infrastructure!
-
cool, that's what we are doing. better than sitting around bitching
-
Exactly
-
this is the stamps attack on CP chart:
-
Many of us are invested not just because we own assets or have built things but invested emotionally in wanting it to succeed, so sometimes things get heated but over the last 9 yrs the best decision has been made given time to cool down, think things through, etc
-
personally I hold under 100 xcp so those price moves don’t mean much to me
-
Open source software life
-
Mike in Space doing the podcast circuit this week. Talking Counterparty and Stamps. I get like 60% of the technical details right, but I say it confidently which is all that matters. https://twitter.com/jakesguestlist/status/1658478397910310916?s=46&t=h1IrRMWKX4jvwsMxM_AqDQ
-
Not running out of a closet bro... load-balanced servers, cloudflare.com, monitoring on all of them.... been doing DB Admin/Sysadmin/Web Dev stuff since 90s... hopefully I know what i'm doing... I monitor performance on a bunch of different metrics... not just saying stuff to say it.... YES, I was a bit of an alarmist (Luke Dash Jr Mode Activated)... but, it brought you to the table to have meaningful conversations, so you could see this was issue, others saw it as issue, and we could work on solutions to solve "abuse" without having to disable features and such. Sorry I have to be seen as the bad guy sometimes... it was not personal. I hope as time goes on, you see that. 😘️️️️️️
-
-
-
That's a non event
-
-
this is a non event - a mere 180 rps? c'mon we are looking at scaling at api usage for 50,000rps
-
and yeah, nothing personal. it's more about business here and growing together
-
i mean i've been doing this shit since the 90's as well. got plenty of war stories. i'm sure we're best buds already. but c'mon this is some weak ass data sizes and load when we should be focused on growing and scaling
-
cool.... and I hope you bring that performance to an explorer and API which can blow xchain API out of the water performance-wise.... but, until we are there... gotta work with what we have, which is what your looking at.... Def could use some help from a SQL query expert... I can throw databases together and organize data... but, optimizing queries is def a black hole for me... EXPLAIN PLAN only gets ya so far.... Could use some help in that regard 🙂
-
If/when you have the time/resources 🙂
-
i appreciate that. assuming we continue in a non-fork manner i'm sure it would make more sense to focus on the broader CP users and build accordingly. we do need a dex anyway.
-
there are a few queries (specifically related to getting order history) that are really slow... optimizing those alone could improve xchain performance a ton 🙂
-
Can you and Mike get rid of the no named assets stamp requirement 😆 that would be a good start
-
There's a perspective, that, "if only Bitcoin Stamps had used named assets it would have resulted in all this xcp being burned" without considering the fact that the reason its been the most successful project in Counterparty's history (by some metrics) is precisely because of it's design architecture and branding. Had we taken the other path where users face friction both in acquiring xcp but in also having to choose a named asset, it likely wouldn't have succeeded. We obviously can't re-run the experiment, but I think its success speaks for itself.
-
Token Stamps also exists btw.
-
This is the FUD we didn’t want to fight.
-
This is fud we will have to fight. But good thing we didn't start with it
-
It is FUD but I’m not interested in fighting FUD I’m interested in launching a successful project without baggage
-
yes, a project I spent 2 weeks on trying to get my arms around everything that wasn't included in "Bitcoin Stamps".. Named Stamps, Dogecoin Stamps, etc 😛 .... i'll fix it eventually... but, to be clear, its a hobby project, haven't seen a dime on it... so, not like "it exists, you should he grateful, your earning $" :P.... it is as it always has been... I build stuff that interests me, not for profit (prolly why I am not a rich bitcoiner) 😛
-
Yes, been hearing the "XCP is a Shitcoin" argument for years... STAMPS def is helping fight that FUD and bringing attention to the fact that "you dont need a shitcoin to use Counterparty" :P... Kudos 🙂
-
Gonna close telegram, watch your interview, and put out the release. 🙂
-
i still need to do the docs on the insufficient btc error with that release so stay tuned.
-
rolling out the current dust fix in this release... once you have github issue created, pls post here and @pataegrillo will dig into it 🙂
-
Did we all just get obsoleted? https://twitter.com/lightning/status/1658497809895809025?s=20Lightning Labs⚡️🍠 on X
Today we're excited to announce the newest version of Taproot Assets 🥕, a scalable protocol to issue assets on #bitcoin and Lightning. With this release, developers have the core set of features to bitcoinize the dollar in a chain-efficient manner! 💸⛓️ https://t.co/7WmeDjNnM2
-
it's a hobby here as well, but might as well monetize it in a reasonable way to be able to scale and see where it can take us all.
-
wow. definitely need to jump on the taproot support
-
we have taproot support ready to roll in a PR... Javier working on p2wsh encoding support... so, TECHNICALLY we will have the ability to move forward with taproot/p2wsh and encoding much larger transactions and files... However, I do not think we should roll out a release that supports writing larger files to the database until we get consensus on out how to stamp/encode files in the most optimal way, and have a solid plan to migrate the file data out of the database...
-
@jp_janssen Any interest in being CIP Editor for the "Counterparty Improvement Proposals" repo?.... still got MandelDuck/Christian as CIP Editor.... Feel like you'd do a good job being a CIP Editor... Only reason I rushed CIP 28 through was because there was not active Editor... but, if you'd like to be CIP Editor, I'd be happy to just submit PR requests and defer to you as CIP Editor to determine appropriate status and merge PRs, etc. ... Pls review responsabilities and workflow... if your comfortable with them, LMK and i'll make you an admin on the CIP repo. https://github.com/CounterpartyXCP/cips/blob/master/cip-0001.md#cip-editor-responsibilities--workflowcips/cip-0001.md at master · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Link
Today we are happy to release counterparty-lib 9.60.2 which includes: - Fix for BTC Balance / DUST error - Mempool Optimizations https://t.co/Q35YwnOmQn #Bitcoin #Counterparty $XCP #XCP #NFTs
- 17 May 2023 (141 messages)
-
Before stamps came around, I advocated for free numerical subassets of named assets. I was trying to read the whole dev channel and catch up, but you all have been busy lately. I went from a few hundred missed messages to over 1.4k! Quite the time to leave the conversation. What did I miss? Worth scrolling up or read the change log?
-
I was also mulling this over few months ago when planning to use CP for an onchain registry for rare sats.
-
Wow, thank you for offering me the role. I will look into the responsibilites before I decide.
Prolly tomorrow. Today is National Day here. As big in Norway as July 4th is in the US.
🇳🇴 -
@reinamora_137 Working on the BTNS Indexer, and refining the BTNS spec a bit to add some more functionality... i'll publish in a bit.... but.. as i'm writing what is possible with this refined spec... figured I'd share what is possible... maybe you can incorporate some of this into "stamps" stuff 🙂
-
## Additional Notes
- BTNS tokens can also be used in combination with other protocols, by specifying the semicolon (`;`) as a protocol delimiter.
- Only one BTNS action (`DEPLOY`,`MINT`,`TRANSFER`) can be included in a broadcast
- BTNS tokens can be stamped using the STAMP Protocol
- By allowing combining of protocols, you can do powerful thinks in a single transaction, such as:
- Issue BTNS token with an ICON pointing to an external URL
- Issue SRC-20 token
- Stamp JSON file with meta-data to BTNS token
- Stamp image data inside a BTNS token
- Reference an ordinals inscription
- Reference an IPFS CID -
How about burns do destructions work via typical destroy method?
-
Thinking about what I’ll need for xcp vaults.
-
DEPLOY/MINT/TRANSFER are the only actions so far... but, added functionality and rules to make "DEPLOY" work like issuances... have an owner, be tranferable, can do issuances, lock supply, etc.
-
You gonna be in Miami?
-
No, Eric is there tho.
-
I'm down to add some new features... for now tho, can prolly just use "TRANSFER" to an unspendable address... or anything that is not a bitcoin address... that will work as "BURN" for now... will work on adding some more features to BTNS after Miami...
-
really lose framework on what you can send to... so... ppl can send tokens to "not a bitcoin address just a text string"
-
-
Cool cool.
-
keeping it open for now... to allow ppl to play more... but yeah, plan is to add a bunch of additional features to DEPLOY to make them more like issuances (all same functionality)... to make BTNS "jump ahead" in functionality of the other src/brc-2 specs.... then can also craft out some new ACTIONS as well... DIVIDEND, BURN, SWEEP... however far down the rabbithole we need to go... its dumb... but if ppl want new features... fuckit, we'll take the lead and put out a spec update each week with a new feature... all the stuff we already got on CP :P
-
Could the broadcast impl one day take priority? Is it more efficient or cheaper?
-
it is neither more efficient or cheaper. Neither is src-20 for that matter. This is degen shit man
-
-
-
In my time in the space, which isn't much compared to the OGs in the room...I've learned that the most absurd always gets the most attention.
At the time I didn't buy BAYC because the utillity was to paint pixels on a potty.... -
-
Crypto Crack heads
-
have you guys seen this on CP? It keeps it in a perpetual restart loop. rebuild, repars, nothing seems to clear it
counterparty_1 | [2023-05-17 14:06:09][ERROR] Unhandled Exception
counterparty_1 | Traceback (most recent call last):
counterparty_1 | File "/usr/local/bin/counterparty-server", line 11, in <module>
counterparty_1 | load_entry_point('counterparty-cli', 'console_scripts', 'counterparty-server')()
counterparty_1 | File "/counterparty-cli/counterpartycli/__init__.py", line 16, in server_main
counterparty_1 | server.main()
counterparty_1 | File "/counterparty-cli/counterpartycli/server.py", line 172, in main
counterparty_1 | server.start_all(db)
counterparty_1 | File "/counterparty-lib/counterpartylib/server.py", line 494, in start_all
counterparty_1 | blocks.follow(db)
counterparty_1 | File "/counterparty-lib/counterpartylib/lib/blocks.py", line 1309, in follow
counterparty_1 | initialise(db)
counterparty_1 | File "/counterparty-lib/counterpartylib/lib/blocks.py", line 293, in initialise
counterparty_1 | cursor.execute('''DELETE FROM blocks WHERE block_index < ?''', (config.BLOCK_FIRST,))
counterparty_1 | File "src/cursor.c", line 236, in resetcursor
counterparty_1 | apsw.BusyError: BusyError: database is locked -
Looks like your database is locked up... did you follow the release instructions and blow away the CP databases? if yes, next time you start up CP, it should download the bootstrap databases and then just resume parsing on them
-
@pataegrillo any ideas? is this an internal sqlite DB flag or an external lock file? ^^
-
FYI... added DESTROY to future plans as suggested 🙂
-
-
exactly, this is a locked database normally caused by a sudden shutdown (or another thing that didn't let the database unlock the database file). For sqlite the lock is an extra file located in the same directory as the database
-
if you delete that file you unlock the database
-
Now that busy error could be also that the library used for sqlite in CP couldn't load the database for another reason like corrupt wal and shm files, but i'm not sure about if it's the same busy error message
-
why not just make it not CNTRPRTY then?
-
Wtf.party
-
-
The difference?
-
-
Right.
-
yup... just new namespace... and the retarded ETH beginnings "DEPLOY" instead of "issuance".... "TRANSFER" instead of "SEND"
-
Now what would be really funny would be a bunch of indexers that all interpret the BTNS data differently
-
double the fun
-
Double the spend
-
double trouble
-
2nd layer indexer wars
-
Or 3rd layer??
-
What if inside the asset name of BTNS we created a new protocol
-
4th layer
-
putting out new specs with new features every week prolly would help... just as tthey catch up, we drop a new version of the spec with new features, ppl can immediately just start using the new spec... and broadcast the spec number as the "value".... btns prefix + value version == infinite project spec versions and easy handling of each 🙂
-
pretty soon gonna be able to do a BTNS transaction that will trigger a CP transaction, which will trigger a BTNS transaction.... crazy times ahead
-
-
-
Always was
-
my 2sats... the Counterparty BRAND is as a historical relic bitcoin/NFT platform.
let it remain that.
this new stuff y'all doing, already applying different sub-brands/meta-brands anyway.
i cant keep up. so CP brand is beneath getting buried anyway.
the broadcast stuff doesnt need "CP".
ppl dont like CP UX anyway.
so if you are literally reinventing CP with BTNS and an indexer, just do it outside CP. -
Yes
-
Ah, maybe I misunderstood what SRC20 did.
-
-
I've a feeling that takes work and that work should be on XCP shoulders instead of, you know, Stamps' shoulders.
-
It’s a fungible token… what can’t it do is the real question
-
If stamps migrates fully to broadcasts like I have suggested, and does away with the "issuance" anchoring they could take advantage of this versioning system as well... roll out a new SRC-20.1, 20.2, 20.3 spec... have ppl be able to use both old specs and new specs immediately, and support both.... can roll out new features in a spec before you even support them in the indexer 🙂
-
Remember there is interaction between protocol, clients, servers, UI etc. it’s an ecosystem. I hear what you’re saying though.
-
anyway... i'll STFU... but, having some fun playing around with this stuff... its silly nonsense, but, so was rare pepe and some of the other stuff that turned into something... so just embracing it 😛
-
BTNS doesnt really though. Unless it is decided it does.
-
regardless, opensource it and ppl will skirt around CP to "broadcast" specs
-
fun ad hoc quasi-protocol'n
-
-
with CP stack? ppl are not too fond of the architecture and code but yes of course.
-
honestly i thought by now, we would be inscribing a la ordinals from CP.
-
There’s really no difference except from a UI/UX pov between inscribing from ord and referencing inscription in asset description and inscribing via Counterparty api or something
-
the difference would be the huge userbase into ordinals using CP
-
and then using native CP features etc
-
instead... competing experiments. its all good. just say'n
-
Yes exactly the UX lol, really just need to chain some txs together and you could do it via a wallet right now
-
You should be able to inscribe via a standard bech32 input in the first tx
-
Bech32 -> taproot, taproot -> bech32
-
in due time i guess. and thanks for not reply “then do it” lol
i’ve been playing catch up despite being “in” early and trying to understand what logically should be done but so much is being done, weirdly -
💯 understand why some of this is being done but not really why…. logically from tech standpoint
-
Do it fast=🔥 but fire burns out quickly
Do it right makes far less money and less traction but stands the test of time -
CP seems anti-ordinals now
-
It's all just a shortcut.
-
i’ve noticed
-
CP has done everything except what i assumed would be done lol
-
i’m a boomer
-
Why do you say that?
-
well, an argument can be made. stamps was worth putting out there. but point me to anything that was a response to Ordinals to directly support it from the CP side, besides inscribe.art
-
Rare ordinals
-
i'm sure once taproot support, it will be inevitable. but CP could be Ordinal-aware wallets and include inscription features, and blended with CP assets (like BRC-20 will soon do)... ordinals + dex + dispensers etc would be powerful and many new users would come. Instead, who has the shiniest new thing thats a copy of the other shiny thing.
but hey, its been a scramble for everyone. -
My proposed ordinal envelopes solution
-
Well the wallet devs are basically me and jdog
-
yeah I love that...
-
And we have limited bandwidth lol
-
no blame, just big picture comments
-
Hiro adding Counterparty support tho
-
I’m sure xverse will too
-
like ordinal envelope idea > BTNS yeah?
-
Of course it’s my idea lol
-
those wallets adding CP is a win. but i'm talking about the opposite.
meh doesnt matter in the end.
i pop in, and think these things.
be cool to talk more about envelope idea more... could try to help there. -
Honestly I’m waiting for this for vaults, the idea of ord<>xcp interop is amazing. Using either tooling for some subset of shared features is gold
-
when you say vaults, you referring to new EV stuff?
-
prob missed the convo upstream
-
Yes. I don’t talk about it much because emblem is a product and don’t want to muddy the waters too much and be “that guy” but yes vaults made using counterparty so the entire concept can live on bitcoin if users want (and do they fucking ever)
-
ALEX Lab
The complete #BitFi via @Stacks . Bring your Bitcoin to Life: launch new projects, earn interest, rewrite finance, reinvent culture.
-
curious how you're approaching it but good to know 🙂
-
I was just thinking about pulling dispenser stuff into stand-alone version wallet and doing some modifications
-
wonder if we should introduce the "RUG" command.... poke fun a the space... it would immediately mint any remaining BTNS supply up to MAX_SUPPLY, lock supply MAX_SUPPLY and MAX_MINT, close any pending actions (DISPENSERS, ORDERS, LISTINGS, etc), and transfer ownership to an unspendable address... 😛
-
renounce you mean?
-
rug-renounce
-
haha
-
its actually interesting idea @jdogresorg because can be gamified
-
yup.. burn token issuance, prevent further changes, mint remaining supply, and burn it all (including right from ppls wallets)
-
if mint-out does not happen before certain time, deployer mints it out and locks it
-
like callback... but you get nothing in return 😛
-
ahhh burn too
-
Made this a while ago: https://xchain.io/asset/A709923891251641011
-
i added ability for owner to pre-mine and issue supply at any point via MINT_SUPPLY... it bypasses MAX_MINT... so asset owner can still premine and mint as much supply as they want.. a way to poke fun a the "fair" mining 🙂
-
well w/o the burn part, it could be way to incentivize minting out... or left over tokens go to deployer
-
totally fair mining... cept for the owner premine, and ability to print supply at any time 🙂
-
will add to RUG to spec for fun 🙂
-
make it do as much damage as possible 🙂
-
the biggest selling point of BRC-20 is the no premine by default (ofc you can still choose max mint lim to max supply and inscribe both together).
even if introducing idea to update the token (supply) is rn against the brc20 vibe. -
this would at least give a use case for betting feature lol will it rug or not
-
haha nice iframes ftw
-
Anyone could come up with their own BTNS actions and indexooors could choose whether to recognize them
-
Could be entertaining to see play out
-
Counterparty Tokens, in an emblem vault, on ETH, displayed inside a Counterparty token..... what are you complaining about @sulleleven you helped create all this nonsense by spawning emblem vaults with @shannoncode 😛
-
token-ception
-
Lol
-
shhh
-
one can only handle so many 🤯
-
@jdogresorg you’re Miami?
-
-
Fly out late tonight... get in at like 5AM
-
@reinamora_137 FYI.. looks like the src-20 spamming has resumed... (not from your service, but seeing a bunch of src-20 stamps being minted)
-
-
mysql> select count(*), sum(length(description)) from issuances where description like 'stamp:eyJwIjogInNyYy0yMC%';
+----------+--------------------------+
| count(*) | sum(length(description)) |
+----------+--------------------------+
| 12083 | 1094858 |
+----------+--------------------------+
1 row in set (0.45 sec) -
Can you please communicate your plan and ETA here?
-
will try to hookup with you
-
You guys want to grab a drink with Eric? My biz partner?
-
Only doing yacht party and afterparty really... rest of time is vacay not biz... scuba diving, etc.
-
Gotcha
-
if Eric is on yacht or at LIV after, happy to have a drink n chat 🙂
-
Is it a TEST party
-
Or are the apes doing it?
-
no idea... last one I did was TEST party in Vegas last year 🙂
- 18 May 2023 (27 messages)
-
you can have him reach out to me. i’m winging it
-
It’s a Shawn Leary deal who organized the TEST events.
https://twitter.com/shawnleary/status/1629223097466339328LinkCome aboard for the 2nd Annual Sunset Dinner Cruise May 18th during https://t.co/ei3oLwbfdR in Miami Beach 🌅 ⛴️ 🥳https://t.co/v3uoSUv1eL
-
Looks like the link doesn’t work though
-
All of these asset transfers are insane. A 10 XCP transfer fee might be needed.
-
-
-
-
-
I don’t know how you would integrate LN in the first place but seems like not having taproot would be a hindrance
-
I see src-20 spamming has resumed.... and no discuszions here
-
I think there are a few services being built, a few might be coming online?
-
3000+ pending src-20 txs.... once I hid numeric assets from the site (cuz it is abuse), seems src-20 has decided to continue spamming an NOT continue woking with Counterparty
-
we determined it's a non-issue for us with the db size and all the things we have been chatting about. If a fork is necessary we are prepared to handle that and take CP in the direction it needs to work with what we are building. CP needs some db upgrades, but it is no reason to leave the hordes of users waiting. We have the eyeballs now, and it could all dry up in a matter of days. We chose to continue monetizing while can and simultaneously work on a broadcast method (and other sw implementations) that work for us
-
Joined.
-
WIll discuss with other members on boat tonight, but at this point, we are out of options. SRC-20 team knows this is abuse, so I feel I (personally) have no choice but to come out AGAINST SRC-20 very publicly,,... which I have avoided doing,. At this point, I believe the fork is the only way forward to stop this abuse immediately. Chat with you guys on the boat in a few hours.... decision will be made tonight,,. I have switched my position and I am pushing for a fork. It is unfortunate that ONE project is causing all this drama,. The path forward for me is simple., Fork to stop abuse, focus on an OPEN system BTNS.
-
getting offline until after tonight on the boat. No more discussions here are needed. The issue has been communicated clearly. Community has consensus to move forward with fee when necessary, it is now necessary. We have PRs ready to roll out a new release with 2 clicks. Will maee decision tonight after further discussions with other communitiy members.
-
i don't see why it has to be such a competitive stance. we can still work together in meaningful ways on the base layer as well. you can fork, you can fork if you want to lol i see a song in there. have fun on the boat!
-
I don't feel that it is abuse and I hope the counterparty community at large appreciates our position. The attention we have brought, the funding that you personally have received, the rise in token price and the offers we have made to help with scaling along with our earlier offer to incentive xcp. Which you personally denied. I'm sure you told everyone about that. End of the day this is only happening because u are memeing the word attack, about a database that would fit on most ppls phones.. whil also building no less than two shitcoin platforms to sideswipe us and consistently not keeping to your word and gatekeepers a project u present is decentralised. I just hope ppl see that. And that they also remember that I arwyn, love counterparty and the community I engage with everyday.
-
It’s unfortunate, I think a fork will harm everyone in the short term.
-
But this is how these decentralized systems were designed, so there’s that too.
-
IMO enough talking has taken place. My viewpoint has been made clear. You resumed your spamming, Your the one who took action to stop the "cease-fire". It is unfortunate that it has come to this. But no further discussions are needed. We know your viewpoint, CP is a dumb database you want to just spam and you dont see any problem with growth at whatever rate you want. Your viewpoint is heard. My viewpoint is this is an attack, I spent all week working to stop this fork, but you forced it with your actions. Everyone here knows this... .you resumed src-20 spamming, with no communication here, and only talk when I threaten fork. It is clear your going to do what you want and only way to "stop" you is fork. Thank you for making this clear. CP will be stronger afrter this fork as it will no longer have this attack vector. Getting AFK to try and enjoy my day.
-
-
No rest… even on vacations.
-
-
No one saying its dumb. We offered to help. I'm nit sure why you are trying to make this point. We offered loads of things to help this work. I personally feel that you have been obstructive, to say the least from the beginning. Its clear to me all the actual community want us to co exist and benefit from all this attention
-
Leave it be for a bit then. Quit poking for a few
-
Yeah im sorry tbh.. makes me sad too.
- 19 May 2023 (156 messages)
-
:( still, take it easy everyone 🧡
-
I really really tried to keep up with the recent XCP dev conversation but life, work, family and the fact this space absolutely blew up lately made that very hard. I’m about two weeks blind to the conversation. I’m very familiar with counterparty, aware of ordinals and have stamped a named stamp of my own a few weeks ago. Can someone please update me on the contention here? Is it all of the ‘A###’ assets being created? Too many 1-1? Actual malicious code injection? Stamps bad? To me my named stamp is just an old school xcp asset that is safer than imgurl and more convenient than arweave. Broadcasts are better than TX why? What does BTNS solve? Trying to fork cp or btc? Several issues could be solved with more wallet support. I’m a big fan of the utility that counterparty can give to the world; the art, and memes are just a bonus that has helped keep me interested. The community is cool too. If you’re in Miami, drink water and apply sun screen. Thoughts?
-
The creation of not only a new namespace but new token implementation on top of numeric assets creates some philosophical questions wrt named assets and subassets which require an XCP fee
-
Something we’ve been discussing and based on conversations I’ve been having in Miami, nearly everyone I’ve talked to thinks adding an XCP fee in line with subassets (which are technically also numeric assets) makes sense from the perspective of the platform as a whole
-
An idea I’m really starting to come around to, putting all assets on equal footing
-
I’m coming around to this as well.
-
At this point, nothing should be “free” on CP
-
except broadcasts
-
We pay fees for asset issuance (besides numeric), sweeps and dividends which I think makes sense as it’s the closest thing Counterparty has to “gas”
-
-
-
Create a class of human-unreadable asset names, whose registration is free. · Issue #372 · CounterpartyXCP/counterparty-lib
That is, allow for both alphabetic and numeric (e.g.) asset names, and only have a fee for the former. How to make this backwards compatible is not obvious---the database won't have to change, ...
-
The PR that created numeric assets
-
@jp_janssen brought up the risk of the creation of a namespace on top of numerics back in 2014 before it was implemented
-
What wasn’t foreseen was the creation of a new asset implementation on top of numerics
-
Mempool creating a transaction acceleration marketplace
-
-
-
-
It often doesn't work well
-
Joined.
-
Thanks for the history lesson. Good read.
-
I had to planned to register 100k+ numeric assets in 2015. Won't tell why not give people ideas, but I was asked to stop after a few k. I complied but we cannot expect everyone to do so on a permissionless platform.
Im in favor an xcp fee but not rushing it. Right now it costs $2-5 in btc fee to register an asset anyway. That should be enough? -
E.g. stamps on free numerics?
-
SRC-20
-
How would you roll it out?
-
It’s hard not to view the cannibalizing of the free numeric assets for a new asset system with a namespace as an attack on the platform
-
I would call it. Using the service. How come when luke says its funny but when it happens here it's code breaking? All I mean is that you guys will implement a charge. But we already offer to pay in the v first place and jdog said no. We offered to integrate xcp burn into mint
-
I think basically we still did.. but it seems we have same end resuly
-
Did you?
-
We cab at least pay our way and help scale
-
Yes.
-
In nit here representing the team just myself. But we did, and for my part I would always be OK with that