- 08 January 2024 (1209 messages)
-
Bro just use an enema. You shouldn't be straining on the can. Poor humans and their fragile digestive systems. Also, everyone should take a FIT test every year - a cheap test five dollar that can detect trace amounts of blood in your stool. And if that happens you can get your ass to a doctor in case its very treatable colon cancer -
Did a little write up for the early AI community, since they are a pretty invested part of the xcp world too
-
I'm glad to see so many people participating in this ongoing discussion on the future of counterparty :)
Personally I'm in favour of the 0.1 xcp fee on numerics, but rather than it being a burn, I like @katiecharm suggestion of fees going towards node operators.
But that would need a major change to CP core.
I would have liked to have seen @jdogresorg stick to the 30 days he committed to yesterday, but he's now updated his xchain.io block explorer to run off his own CP that filters out numerics, due to an increase in issuances and sends overnight.
Of course, xchain.io is his project, his infrastructure and his call to make. -
he can remove numerics without needing to fork the ledger -
@jdogresorg sorry I missed pasting, so see what you think of my addition :)
I'm fine with your decision re. xchain, I understand why you have brought it forward, just my personal view to state that sticking to the announced 30 days would have been much better for discussion and stability for everyone.
Having said that, I know it's a real cost impact and you have been talking about this for a long time. -
His change does not affect CP v9.61.1.
He's just choosing to run his own ledger now.
Two ledgers definitely creates challenges for many, which is why I think the 30 days would have been prudent, to allow all this to be worked through. -
thats not true ledger is forked so creates many posible issues
-
I have also noted the arguments re. the bottleneck.
"Counterparty is parsing blocks good the bottleneck is in the counterparty2mysql PHP script running for xchain right?"
Well, that may be so, and it seems that needs addressing.
I'm not sure what level of complexity lies behind optimising the counterparty2mysql PHP script, and it seems that's perhaps an area for everyone to understand better? -
So if I send assets using freewallet and then using like I don’t no stamp ninja wallet we have a problem? -
Just don't use JDog's ledger/DB?
-
Freewallet still on v.9.61.1, now cannot see or transact on numerics there anymore.
-
through interface i guess using the api is possible
-
Yeah but won’t the other assets the named ones also be on a different ledger
-
You can still send named assets on stamped ninja
-
Double spend? Haha I don’t no am just throwing stuff out there
-
I am not a dev
-
only for ppl trading in numerics -
This is helpful info from @jdogresorg
-
Freewallet uses api.counterparty.io to generate txs.... api.counterparty.io is load balanced between api1 and api2.counterparty.io... both of which will be staying on 9.61.1.... TLDR, Freewallet generates txs using 9.61.1
-
no changes between 9.61.1 and 9.62.0 except XCP fee on numerics (and a couple bugfixes)... so regardless of if they are using 9.61.1 or 9.62.0.... txs are generated the exact same.... just processed differently on 9.62.0 (numerics without XCP fee not valid)
-
No double spend on named assets
Freewallet generates txs using 9.61.1 -
Gotcha
-
So long as all wallets keep generating tx's using 9.61.1 everything is cool, only numerics balances will gradually diverge between core 9.61.1 ledger and JDog's new 9.61.2 ledger used for xchain.io
-
Counterpart Cash Association (CCA)
XCPC - Counterparty protocol for Bitcoin (Cash)
-
Nothing happened, that was Julian Smith talking about porting to Bitcoin Cash. He never went ahead with that.
-
they didn't have the infrastructure or devs to support a fork... so no fork ever happend on another chain
-
id love a bitcoincash fork -
would be fun AF
- 09 January 2024 (709 messages)
-
mmmm yes, but we have dogeparty so.....
-
Bsv -
-
you can mint whatever you want ova there
-
Official Dogeparty Chat
This group is for discussion of the Dogeparty platform, which is a token system which runs on top of Dogecoin. https://dogeparty.net https://dogeparty.xchain.io https://twitter.com/DogepartyXDP https://www.reddit.com/r/DogepartyXDP
-
Don’t stamps take up less space in a block than ordinals? -
btc has the most robust history and security through its ledger
-
its why XCP was made on bitcoin
-
most secure
-
If you want something to persist you’d use btc over bcash
-
or should say 'using confirmed btc tx's'
-
they do
-
errrywhere mate
-
maybe people should up the prices on their btc art ;)
-
because its on the most robust chain
-
and is worth more
-
-
xcp upset alot of people back then too
-
or you just saying they look "badass"
-
being a jesse james to the Luke Jr's out there?
-
maybe the bitcoin devs shoulda dealt with block size and byte size back then!
-
-
but hey they forked that too
-
litecoin, doge, bch etc
-
or all of this is one big experiment and no one is in charge except for us
-
-
..... when was the last time xcp was used to vote on anything
-
link the XCP forum post, lets read it
-
you dont like the CIP process that has been used since oct 29, 2015?
-
It would be ideal for large Ordinals inscriptions, I'm surprised it hasn't been done already, or perhaps it has and it's just not widely known yet?
-
2017 foundation elections... about ~100K votes total cast if I recall
-
[ANN] Starting the Foundation Election 2017 voting period
The Counterparty Foundation is announcing the start of the 2-week long voting period for the election of four community directors. The voting will start on block 462450 and end on block 464556 Start and End of Voting Start Block: 462450 End Block: 464556 Candidates Michael Sullivan Shawn Leary John Villar JP Janssen Dante DeAngelis Trevor Altpeter Voting Procedure Users who want to give their votes to one or more candidates may do so by broadcasting a message with the following parameters: ...
-
and there it is
-
-
cips/cip-0001.md at master · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
we now have 3 maintainers
-
and JPJA is the CIP editor
-
potential?
-
no you can look up who the maintainers are at this exact moment
-
especially when you aint interacting in the github
-
you sure?
-
false
-
-
What have I missed? -
Is there an open CEO position for THE Official Counterparty?
-
lets check how many of these CIP's these maintainers have successfully drafted and completed.....
huh looks like they have a track record of developing drafts for improvements and then CODING them after feedback, consensus and testing -
?
-
sure you can make the argument he merged them after consensus for the devs that actually engage in discussion within the github
-
but what about now?
-
can't blame him anymore, cause he aint maintainer
-
and yes almost every upgrade was met with contention
-
always has
-
oh yes
-
go read it yourself
-
almost every upgrade has at least one individual against it
-
or against some part of the code
-
always been that way
-
and..... its ALL in the forums and github
-
oh history runs deep my friend
-
Proposal: Protocol Change to use BTC instead of XCP for Asset Issuance
PROPOSAL: Change Asset Issuance fee from XCP to BTC. PROBLEM: The Total XCP Supply is 2,648,735.92. The cost to issue an asset is 5 XCP which leaves us with a hard limit on asset issuance of 529, 747 for all of Counterparty. For any company using Counterparty to create assets, this is a hard ceiling on the business and incentive to move to other protocols to build asset businesses onto of the bitcoin protocol. I don’t believe Mastercoin has this limit. SOLUTION: I am sure we are using XCP t...
-
yes.. even subassets was a huge drama... ASSET.SUBASSET or SUBASSET.ASSET.... some wanted domain structure.. some wanted different... all cp releases get some ppl upset... NEVER gonna make everyone happy... especially when its percieved/framed as changes being FORCED rather than (general community agreed, but I dont)
-
coming from someone who has never written a CIP, who's to say what is junk
-
is this junk?
-
cips/cip-0007.md at master · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
this one?
-
Proof-of-concept VM Development
So i’ve recently started to develop a minimal pure python Virtual Machine tailored specifically for counterparty. I’m starting this thread to keep note of development and design decisions, and also to get input from the community regarding what should the VM do. FAQ Why not use EVM? EVM was designed with ethereum blocktimes and specifics in mind. CP has already a lot of groundwork regarding tokens, bets and a lot of useful functions that don’t need to be recoded in a smart contract. Isn’t...
-
and theres no input from you in the github (and many others) cause yall never considered being a part of the process
-
Please post your videos of frog catching, cat herding, gator wrestling and puppy soothing.
-
thats just like your opinion man
-
-
so draft a CIP to make clarity around voting?
-
we would all love to see it
-
so many individuals in here love to talk, but when you show them how a CIP works and how to disagree/critique it on the github.....
crickets -
btw boost i love you its just frustrating for me to see
-
so many talented individuals not getting involved in the correct way XCP has always done it
-
-
My I'm reading the chat out loud in my house. Last 2 days it's my son's story time.
He's 9months... for him this is a white knuckle thrill ride. Not sure who's side he's on yet.
My girl overheard the last 30min...
She said "tell them to shit on the floor"
I don't know if it's helpful...
But I'm here with more unconventional wisdom if yall need it -
RUNNNIN IT UP
-
how can you know if its worth the time if you have never tried?
-
vs indiviudals that have tried, failed, or succeeded for almost a decade?
-
it sounds like you have more of an existential crisis of "if i speak my mind there they just wont care so I wont" HMPF see im winning!
-
you sure?
-
show me the githubs and the forum posts
-
you made a very detailed statement here
-
back it up
-
at this point i dont know what we are discussing
-
voting? CIP's? or marketcaps?
-
oh JPJA is here
-
ask him about OLGA
-
-
or Cornholio
-
ask him about CCSATOSHI
-
or Theo
-
ask him about BEEP
-
whats the question again?
-
-
I like Dex... Dex gud
-
keep up
https://github.com/CounterpartyXCP/cips/blob/master/cip-0030.mdcips/cip-0030.md at master · CounterpartyXCP/cipsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
2023-07-11
-
This is the only reason for this song to exist
"Cmon yaaaar... cmon Johnny 5" -
-
-
There are a few important factual errors here. Specifically, tokens don't require any xcp to send, not even with Jdog's fork. It's about burning xcp during the mint process of the token. Also: "Stamps store the file header unlike Ordinals"... not correct either, the entire file gets encoded in transaction outputs. In that way it is similar to Ordinals (though Ordinals stores the file data in a very different way). -
All up in the videos... dancing 🕺🏾
-
-
You would think that assets should require xcp to send tho. That would be in-line with spam prevention. You could cause a lot of traffic just sending assets back and forth which creates a trail that gets recorded. Imagine how scarce xcp would be if every action required burning some amount of it.
-
it really looks like you guys just want to kill xcp and have it all on stamps. keep dreaming big guy! lolz
-
-
Lol. Good troll, but send tx are small -
Stamps creations aren't at all
-
Right so they would require a very small amount of xcp
-
If I want to sweep my address it requires xcp, so why wouldn't an individual send? Doesn't that create more of a trail if I do 30 individual sends to a new wallet vs 1 sweep?
-
sweep has the potential to create thousands of database records in a single action... so, requires an anti-spam mechanism to protect CP from someone just spamming sweeps n taking counterparty down and exploding the ledger
-
Not sure what's the size of a sweep
-
To my limited understanding it's not every... just creation.
The end point of the fee seems to be the biggest issue, and its lack of helpfulness to the root problem.
So hypothetically instead of an xcp fee... if there was a btc fee (small obviously) associated with name creation that went directly to running cp would THAT be contested?
Because if the conversation I am seeing here is being had in earnest. It would seem that instead of a .25 or .1 or whatever the XCP fee, if numerical just had a BTC fee that went directly to funding CP everyone would be happy... no? -
the sweep tx itself is very tiny... fits in OP_RETURN I think... tiny TX, but possible big database footprint in CP
-
BTC fee works as anti-spam mechanism in most cases... but not all.
-
-
I would love this. But its that last mile problem...
-
You could just burn the bitcoin but that only helps the miners
-
But let's say it went to a special address instead: now you need people involved to decide where that money goes. Not so simple in a "decentralized network"
-
and to the node operator?
-
each node could has an asociated address
-
at least works for infraestructure costs
-
But is the ecosystem "infra" divided up in such a way that each node is an equal participant? Or am i just collecting a bunch of money but everyone is using someone else's infra
-
Can't be decentralized, it's not a network
-
Nodes are just readers
-
readers and writters
-
There is no xcp "node"
-
I think its a hard problem and you would need to introduce human custody and decision making
-
you can connect all nodes between them also
-
Sounds like this also needs to be increased
-
and have loadbalance between
-
there is a api that generates txhex -
Yeah, but it's not a "node", like we understand in the crypto environment
-
it's the source off 'truth'
-
There's still the "tragedy of the commons" where 1 party or 2 or 3 run the high-traffic explorers while other parties might be running the popular (and lucrative) front-end minting services.
-
you can connect them i am not telling they are connected ser
-
dont delete messages
-
Not a writer either. It gives an API used by a wallet to build the transaction
-
It always just read
-
it literally writes the transactions
-
on it... we adjusted the sweep fee from 0.5 XCP to a dynamic fee based on size of the records written to the database... that is already in counterparty... added it in the 9.61.0 release... https://github.com/CounterpartyXCP/counterparty-lib/pull/1274Sweep new fee by pataegrillo · Pull Request #1274 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
well yes not a writter as it is not writting itself to bitcoin but gives you the ability to write them
-
then you sign txhex using coinb.in or I do
-
Yeah sure however... put it in a lunchbox... I'm retarded lol
Finer points will escape me
But would THAT (on the surface) be a solution, and if not why
Trying to understand -
any other actions bloat the cp ledger? dividends, etc? we should be looking to add or increase the anti-spam countermeasures as the trolls will look to exploit every possible scenario
-
broadcasts
-
IMO we definitely need to address 0 quantity records.... a bunch of bloat is that... over 1Million records in CP database last time I checked I believe.... https://github.com/CounterpartyXCP/counterparty-lib/issues/1113zero quantity records / database purge · Issue #1113 · CounterpartyXCP/counterparty-lib
Still seeing issues with 0 quantity records being created... this is bloating the database unnecessarily.
-
Hilarious: I literally suggested this and now you're onboard. You're welcome.
-
are broadcasts abusive? are they taking down counterparty? dont seem to be.... but absolutely, if any one function of counterparty starts stops things from working fast, changes should be made... I would probably be in support of a fee on broadcasts if/when they become a problem that needs to be addressed.... nice job trying to make it about BTNS again.. losing argument tho.
-
the attack makes us stronger thank you for bringing it to our attention
-
btc balance is taken from 3rd party service.... has 3 failovers... so should work... https://github.com/jdogresorg/freewallet-desktop/blob/master/js/freewallet-desktop.js#L1173-L1249freewallet-desktop/js/freewallet-desktop.js at master · jdogresorg/freewallet-desktop
Desktop wallet for Win/Mac/Linux which supports Bitcoin and Counterparty - jdogresorg/freewallet-desktop
-
Anyone EVER answer this question
-
I guess you should hear it from the horse’s mouth. Let me switch to pc easier to type
-
-
Alright, so there are 2-3 reasons why numeric assets were chosen over named assets. Some are practical while others more ideological. As I'm sure you're aware Ordinals dropped a year ago and were an immediate success. I personally attributed a lot of this success to being a "Bitcoin only" play and I think the market agreed. Ordinals were seen as "the first NFTs on Bitcoin" even though Counterparty had been around for a decade. It didn't help that Casey made the whole, "Ewww... XCP" comment on his podcast. Around that same time, I was putting together the concept of Stamps with Arwyn, Kevin and even Joe Looney. We knew that there was a way native to counterparty where base64 image data could be encoded into transaction outputs so we could match Ordinals on the "onchain" meme. But XCP was considered "baggage"... "shitcoin baggage"... right or wrong, that was the perception. In order to position Stamps as "Bitcoin only" it made sense to jettison XCP which was done through use of numerics (named assets require burning xcp to mint). With numerics all you need is Bitcoin. Its clean. Its easy to market. It's easy to onboard as new users don't need to learn about or acquire xcp. So while there was a practical aspect to it (less friction) there is also an important memetic aspect to it: xcp is seen as a shitcoin and thus would soil our "Bitcoin NFT" project. You can argue that we made the wrong decision and Stamps would have been just as successful had we incorporated named assets, but we can't rewind history. But we can look at objective metrics: like the fact that 20% of all Counterparty assets ever issued took place in 2023. As well, the numeric aesthetic was kind of reminiscent of "Ordinal theory" which is a bunch of numerology nonsense, so our numerics fit in well to onboard Ordinals users. Basically, the idea was to put Counterparty under the hood (the plumbing) and completely market Stamps as its own thing, not a decade old technology. I think it worked. Others can disagree.
-
Before stamps I think also like 60% of assets were created within the last 12-24 months -
very likely. Fake Rares and other series are quite popular
-
Fake Rares only had like 4 series as only selected artists
-
But yh now more welcoming
-
I got into Series 4. A highpoint for me.
-
I’ve never tried to sell XCP on the DEX for BTC….
If you put a sell order for XCP on the Dex for BTC, does it require any signature from the seller of XCP after the sell is placed or will it just be auto matched when the BTC buyer places the order? -
it works over a certain BTC amount rn, Freewallet is the only wallet that supports it at the moment - and i wrote about how to use it here:
https://gist.github.com/davestaxcp/1e2cc086a13c9a2d045876852b57e5be#understanding-btcpay-and-the-btctoken-on-the-dexFreewallet FAQ 2023 v0.9.23 - Write Up - Draft #5Freewallet FAQ 2023 v0.9.23 - Write Up - Draft #5. GitHub Gist: instantly share code, notes, and snippets.
-
Thanks
So if an XCP sell order is placed, and a buyer comes along and is buying > 0.001 in BTC, the order matches and it works basically like a dispenser without the risk of getting rug pulled -
exactly
-
ive always wished this was used more
-
and could be theoretically done with pbst's for XCP tokens to be traded on places like magic eden
-
So we just need liquidity of XCP sell orders for BTC on the DEX basically
-
but i am no dev
-
and a better wallet infrastructure so you dont have to leave the wallet open
-
again, im not a dev, not sure how that would work
-
But if the XCP sell order is sitting there already, that will match instantly with the BTC seller
-
The XCP seller doesn’t need to leave the wallet open?
-
yes
-
the function was called BTCpay when used on the XCP DEx
-
Oh the XCP seller needs to do what?
-
sorry i thought you meant like an XCP/TOKEN pair
-
both users will have to have the wallet open at the same time - ive used it - works great for OTC
-
i tested it with Al
-
PSBT is the way to go for secure trades like ordinals does will open the door to be listed in big marketplaces
-
XCP and Stamps too tbh -
would require a trusted 3rd party to hold BTC and monitor for order matches and send the BTC on your behalf.... the current method of leaving wallet open is definitely less than ideal... but it is trustless... doesn't trust anyone else with your BTC but you
-
xcp wallet works great for me
-
All series are curated and only one had a guest curator so I’m not understanding this statement
-
How did you become a moderator? lol.
-
I should probably know this by now but selling XCP is not something I’ve ever done except for Corn and Pepe cards
-
What are the actual mechanics involved… so order gets matched… buyer has x number of blocks to get a confirmation to lock in the trade? What if there’s mempool congestion and the bitcoin arrives late? Is the xcp seller stuck in a trade they can’t close?
-
Last time I was in here you got banned. Gives me hope.
-
Lmao that was almost 6 years ago
-
Thank you for a direct answer
-
That's not exactly true... fakes, Danks, commons, wojacks, and a host of other communities create assets all the time.
And when ordinals launched fakes was on series 12 -
I can’t remember exactly off the top of my head but the worst case scenario for either party involved is an unfilled open order. I can’t remember the number of blocks btcpay searches. I’m pretty sure either party can cancel at any time if they were impatient. Nobody would lose anything except a txn fee -
I think it is 10 from previous conversation
-
Or better I thought
-
See I'm thinking... there is a point at which BTCPay sends the BTC, but before its confirmed in a block... so either the order has to remain open (indefinitely?) or it can be closed, the seller gets the BTC but doesn't send the asset. What am I missing? I get that its like 10 blocks and that should be acceptable 99.9999% of the time, but there are no guarantees with the mempool
-
-
From what I understand the ask is searching for the parameters of a satisfying bid, and the bid is doing the same. Both orders carry an address to answer the question of where to send. Since it’s one transaction I don’t think there’s a way to stop partially through the transaction, allowing only delivery of the btc or asset without the other. The only way would be a cancel transaction processing faster than a bid or ask that would fulfill the order. The cancel transaction would cancel the order and when the other party’s order confirms it would sit unfulfilled because they were too slow.
-
The Bitcoin txn is broadcast; the cancel order is placed. It’s gotta close at some point and that BTC could be stuck in the mempool for even longer. I don’t see how you get around that
-
You can’t get around the suffering of an insufficient transaction fee. I don’t have enough background in this so I don’t want to spread false information, but I’ll try to remember. The order with the sufficient fee will respect the other order in the mempool for a window of 10 or 20 blocks before that window closes. If you are impatient you can cancel your order because the other party used a low fee, or you can just do nothing and the window will close on its own. If your order spots another match from a different party in the mempool it will open up the window for them for another amount of blocks until it closes the window or you send a cancel transaction. Please, someone correct me if I’m wrong and also I’m not sure if I’m answering your question lol
-
I’m going to sleep
-
Most people waited 10 months or more , not many artists excepted, common knowledge, now any riff raff allowed
-
I think what his saying carso it was the same old circle until it brought In new faces
-
Commons was made "because boost had a 2 week holiday"
-
I think fakes saw the dank juice and wanted to be more dank
-
As in more accepting
-
That was short-lived. -
I just withdrew CIP29 which justified xcp fees on numerics.
I wrote that CIP long ago and I think it is outdated.
Whoever still wants this fee, please write a new updated CIP to replace CIP29.
https://forums.counterparty.io/t/fee-on-numeric-assets/6601/6Fee on Numeric AssetsI suggest adding a 0.01 XCP fee on every issuance (initial and subsequents issuances alike). Also, invalid issuances should be ignored and no longer be stored in the DB. I am against the planned 0.25 XCP fee on numeric assets. Why fee on every issuance From my understanding, the problem lies with the issuances table. Many use cases, like data storage, should move to broadcasts. To encourage this, a fee must be applied to every issuance, not just the first one. Otherwise you can issue an asset...
-
I get the reasoning but
1) What happens to the ‘Bitcoin only’ purity test if an XCP fee gets added? Also do you think the market will assign more value to the assets that didn’t require an XCP burn?
2) Will named Stamps now be the alpha as there is less of them compared to numeric?
3) I’ve noticed a few of your posts about Stamps having little limitations and it being some sort of free market pursuit, yet how many Stamps were issued before the pleb public knew about them?
4) I’ve also noticed Casey was criticised for imposing his views/parameters on the protocol, isn’t the idea that a named asset = not a Stamp factually untrue, but is a “rule” in the system?
Nothing against Stamps, just interested to learn🤝 -
What bothers me with Stamps is the idea to use Counterparty protocol but censor Counterparty at the same time.
I think it's logical to not accept the named assets but not ok to refuse sub-assets, which are numeric assets with an assigned name.
They are totally valid numerical stamps but they are "banned" because they use Counterparty, while they could be displayed only as numerical assets without their name. -
depends what your selling it for
-
xcp is the asset of which there are now multiple balances of depending who you ask
-
it should be fine to trade for xcp as that assets exists on both sides of the fork (but in different amounts)
-
As I understand it not using named assets is due to xcp required, subassets require xcp too so for stamps to be logically consistent they can't use subassets
-
sub assets are numerical assets that can be referred only as numerical assets
-
each directory sets its own rules
-
ideologically they not alligned
-
you don't have to adopt the associated name
-
which means refusing sub asset is censoring the usage of the counterparty protocol
-
it's a directory choice not protocol censorship
-
yup, it's a censorship at the project level
-
cp is not being censored by bitcoinstamps
-
you can stamp subassets named assets and numerics
-
not all websites show all assets
-
rpw doesn't show fakes
-
named assets != sub assets
-
subassets are numerics but not all numerics are sub assets
-
there arec2 types of numerics .. those that burn xcp and those that don't
-
that's the protocol
-
stamps can't be spent according to project rules.. but they can in protocol
-
project rules and protocol rules are different in many ways
-
yup, I understand that
-
the protocol has 3 assets types 2 of which require xcp one that doesnt
-
2 assets types
-
it's numerical or named
-
at the protocol level it's 3
-
sub assets are enhanced numericals
-
else xcp balances would be the same on each fork
-
its actually 4 asset types now .. named, subasset, paid for numeric and free mint numeric
-
J Loone Brickens 🧱 (@wasthatawolf)
Counterparty Fork Safety Tips To keep your pepes safe... - Do NOT use http://xchain.io, it is running an out of consensus fork - Confirm address balances, open orders and dispensers at http://xcp.dev before making any rare pepe trades or purchases
-
Are there 300 unique RAREPEPES or 300 x 1 of the same ? it all depends how one decides to interpret the data
-
There is no “the mempool” every mempool can be different though they tend to overlap significantly. But the point is you can’t “trust” what’s “seen” in the mempool. Unless someone can tell me otherwise, this indicates to me that the DEX when used in conjunction with Bitcoin isn’t actually “trust less” as there is a potential timing attack. It would be difficult to execute but I think it does exist.
-
Btc dex is trustless. After two orders match (confirm in block), the buyer sends btc to settle the trade.
-
Ok so the protocol escrows the send token so the seller can’t cancel, right? And then if the BTC doesn’t arrive after 10? Blocks the order gets cancelled?
-
What if it takes 11 blocks for the BTC to arrive?
-
Or is it an unlimited amount of blocks and the seller is trapped in this sale indefinitely?
-
20 blocks yea.
-
Seller receives btc but buyer does not get his token.
-
Right...
-
So its like... normal these days with mempool congestion to send a txn you think has a really high fee and then it takes 200 blocks to confirm because some BRC-20 free mint suddenly starts.
-
This is the New Normal
-
So clearly not trustless. It's basically susceptable to the same issue as dispensers just slowed down where finality takes 20 blocks instead of 1
-
I guess
-
Trustless. Up to buyer to pay high enough fee, adjust with RBF if needed.
-
you could use that same argument for a rugspencer. "Bro, you should have paid a higher fee"
-
By this logic dispensers are trustless too
-
Which is all the more reason to use XCP on the DeX and not BTC
-
I agree.
-
No. Rugspenser is the race for highest fee for one particular tx. To rug a btcpay you'd have to push the fee up for all btc txs for 20 blocks. Would cost millions.
-
No you wouldnt this literally happens every day now. A BRC-20 free mint starts and suddenly its 300 sats/vbyte
-
if you got a brc20 and src20 and a btns all dropping at same time fees will be wild
-
Your algo should automatically increase the fee to 301 then
-
The mint starts 10 seconds after I hit send. I used 200 sats/vbyte and then it spikes to 300. I guess I can RBF at that point (so are we saying don’t use the DEX with legacy addresses?) I fail to see how this differs in a material way from dispensers. You can RBF those too.
-
RBF didn’t exist (the spec) in 2014 either
-
you can rbf on any address
-
That’s why I said “the spec”
-
It wasn’t readily available in tooling
-
no its not readily available but possible
-
I can 51% attack the network and rollback the chain too. Is the realm of “what’s possible” a reasonable expectation for the user? They use tooling. That’s what we mean by trustless not doing exotic things
-
If exotic things are possible then they will eventually happen, we need tools that are robust
-
Back to my point: up until even last year it was probably laughable that fees could spike at a moments notice to 300-500 sats/vbyte. But that’s the world we live in now so I don’t think it’s reasonable to call the DEX+BTC trustless if reliant on a specific block count settlement.
-
burn keys were once considered exotic
-
tool were made to make them a every day thing
-
spending baremultisig utxos is exotic - but it will become more commonplace eventually
-
You don’t think they can/will remove it at the protocol level?
-
its a real possibility
-
CP is downstream of BTC
-
Why would BTC devs remove a way to spend/reduce UTXOSet ?
-
that would break the social contract
-
would result in a hard fork
-
I expect the potential for a hard fork and different utxosets as a result will ensure the spending of baremultisigs remains possible and fully in consensus
-
They did already cut OP_Return from 80 bytes to 40 bytes.
-
changing op return length is not changing spending conditions
-
op return is not in utxoset
-
Multiple op_returns for all would be nice but Luke wants less
-
As i understand it the reduction in op_return bitd was instremental in the the baremultisig output counterparty has
-
Btc dex risk can be made about as low as taking a flight.
Rugspenser is a different animal. If seller and buyer enters an RBF war the fee can reach 1000s of sat/b before the tx confirms at a random time. Both parties have a 50% shot at winning. -
The rugger can "afford" more fees if they are to retain a high value asset
-
GM -
!
-
where is the best place to discuss the counterparty fork ?
-
and it's implication ?
-
also I have a question for you @jdogresorg on freewallet. Inputing counterparty passphrase doens't work anymore. (Invalid passphrase) it's very surpising because it's not version dependant. On my version that it always worked suddenly stopped working, some of my collegue have this issue since long time but now it seems that it's not working for everyone
-
this chat has the most members but the github is the 'propa' place
-
is there any thread on the topic on github ?
-
I dont think so Github participation is not great.
there is this thread on forums
https://forums.counterparty.io/t/fee-on-numeric-assets/6601/5Fee on Numeric AssetsI suggest adding a 0.01 XCP fee on every issuance (initial and subsequents issuances alike). Also, invalid issuances should be ignored and no longer be stored in the DB. I am against the planned 0.25 XCP fee on numeric assets. Why fee on every issuance From my understanding, the problem lies with the issuances table. Many use cases, like data storage, should move to broadcasts. To encourage this, a fee must be applied to every issuance, not just the first one. Otherwise you can issue an asset...
-
Add 0.10 XCP fee on numerics by jdogresorg · Pull Request #1298 · CounterpartyXCP/counterparty-lib
This pull request puts a 0.10 XCP fee on numeric assets and activates on block 829,020. Activation Logic 144 blocks/day x 30 days (1 month) --- 4,320 blocks 824,700 current block + 4,320 blocks -...
-
There is no trust necessary between the parties. The buyer must trust themselves to use a proper fee and trust their timing. It is not without risk though, as with anything in crypto. I think we all learned a little more about btc pay through this convo which is great! It's too bad the counteryparty native dex token is viewed so negatively. The dex is a great product
-
did any new numerics get made and pay the fee yet? -
nope -
Rugged 🤣
-
why would anybody in these circunstances 😬
-
the question would be how many people have compiled a wallet with the lib
-
Im guessing few
-
what was rugged? -
i followed along through the process linked on xcp.dev
-
yes
-
didn't see it in xchain
-
i did it yesterday to evaluate situation
-
xchain still filtering them
-
all numeric payed fee or not
-
ou right
-
chttps://stampchain.io/asset.html?stampNumber=245004
-
any listed for sale?
-
or how can i buy 1
-
not yet
-
will open dispensers as this is history
-
if you paid the fee i wanna own your stamp😁
-
the result of this mint was that in 62 ledger the address who minted it result in 9.90 xcp and in 61 this same address has 10 xcp
-
its like a schrodingers fee - only when its observed does it exist
-
is not funny this result but this is what a hard fork looks like
-
-
you cant see unless you run jdogs version locally
-
the fee i mean
-
dont be evaluating too hard bröther. Give them the wrong idea -
almost 2k$ dollars to issue and eval situation + 0.5$ XCP of antispam fee
-
It’s different than a dex trade not involving BTC. Worst that happens is that the trade doesn’t happen. With BTC you can actually lose the BTC.
-
I don’t want to beat a dead horse and I’ll drop it after this, but what you’re describing “pay the right fee” would equally apply to dispensers. Of course, “higher fee” solves everything I guess.
-
I know many of you may not agree with the recent actions or directions I am taking things, which is fine... This is stressfull for everyone involved.
However, I want to do everything I can during this strange time to make sure that loss of funds are prevented. To that end I have made the following changes to XChain:
- Updated transaction API endpoint to check if tx is valid on both 9.61.1 and 9.62.0
- Updated transaction API endpoint to pass new 'valid' param to track if tx is on both ledgers or just one
- Updated all transaction pages with a message to not trust the displayed data, to verify with other explorers, and provided easy links to click to memepool.wtf and xcp.dev
- Updated all transaction pages to indicate if tx is seen on both ledgers, notify of status, and turn alert box red/scary if tx is not on both ledgers. -
Transaction pages with header that indicates if tx is on both ledgers
https://i.gyazo.com/50c2c4121b52d20f6a5faf69a1d2ae4e.png
https://xchain.io/tx/1cad7e7db1e29be1dc4ef1e80550283cf5ce6afb741aa94d9f0e378088ae8355 -
Transaction API endpoint updated with valid param
https://i.gyazo.com/d628e3e0898dfe285cb6a99705453798.png
https://xchain.io/api/tx/1cad7e7db1e29be1dc4ef1e80550283cf5ce6afb741aa94d9f0e378088ae8355 -
I need to take a sanity break and step away from the computer / drama for a bit... but couldn't do it until these updates were made.
If you find txs which are valid on one ledger and not on another, and xchain is indicating that the tx is valid on both ledgers, please reach out and let me know... I want to make sure that I do my best to highlight any ledger differences and keep people as safe as I can during this fork. -
appreciate everything you do jdog - i wont make it to TEST this year (again) as i have a memorial to attend but i hope it is filled with fun and relaxation for you and cant wait to make it out next year - keep crushin!
-
Community is the collateral damage here
Stamps crew can step up and ask for the fee to be added to the repo
Or not and each day passes and things will only get worse
The stamps crew is running the official repo so they are not in the wrong
I personally would look very fondly upon them if they did so, but obviously their right to say fuck off, we’re not in the wrong -
adding fees now doesnt fix anything ledgers are diverged is not possible to merge now
-
The ledgers have diverged. Its too late. Even if the fee was added now, there's no way to get back into alignment with xchain. There are 2 histories
-
Jdog would have to merge the non fee A assets created after the fork?
-
This won't fix it neither as there is discrepancy in xcp balance too
-
It impacts named assets too. Imagine a dex trade for instance.
-
So basically he would have to jump back to the original
-
You trade it on one fork but the txn is invalid on the other so now you still have it but sold on the other
-
Yea, but minimal so far, but as time passes, it only gets worse
-
Exactly. Tick Tock
-
Yea so if the fees were added, he may be willing to jump back
But I mean I get it -
Grass and elephants ser
-
false, CP devs / community have the following options :
- Merge my 9.62.0 release with my activation block.
- Merge my 9.62.0 release with a DIFFERENT activation block (no more than 1 month out)
- Put out their own 9.62.0 release with a fee on numerics
- Do nothing, let the ledgers continue to diverge, and blame J-Dog for everything
Yes, this situation we are in is shitty, but i'm not backing down, and wont run any version of counterparty-lib on XChain that does not include an XCP fee on numerics...
I dont feel Counterparty should allow spamming of 10K PFP collections unfairly (everyone else pays an xcp but numerics), and I am tired of endless talking in circles while scambling to keep everything running.... end result is nothing moves forward.
I will say it is interesting to see people who previously said they were in favor of an XCP fee, now change course entirely... but hey, ppl entitled to their own opinions... just wish ppl could be real and not say one thing privately and another thing publicly... but i digress
The next move is on the Counterparty devs and community to move CP forward.... I've done all I am willing to do at this point. -
nothing has changed in freewallet.... so dunno why your having issues with importing a passphrase... maybe check to make sure its a counterwallet passphrase and not a BIP39 passphrase
-
more questions arising in the rare pepe chat as well, probably need an explainer of what the current situation means for existing assets
-
Any of those options still continue with diverged asset balances on the forks - even if fees are added later in the core CP bits since balances are out of whack. -
Bingo. -
Just out of curiosity, does anyone here collect the works of Dan Dark Pill? -
Yes I do love that dude
-
He allegedly makes Danks too 👀
-
I have two of his pieces and have no idea what they’re worth: MODERNXIII and MODERNXIV.
Only 12 of each were made. -
the fee is only deducted on xchain if you happen to have XCP in your wallet. If you look at xcp.dev you'd have a higher XCP balance, and no fee charged on the same asset.
-
costs money not to be displayed on xchain is all there is to see here.
-
yes ser
-
-
this one was the first in pay the fee
-
how did you get them
-
I picked up his one of one on block 777,777 https://xchain.io/asset/THEPEPEWAR
-
He sent them to me. I’m the subject of MODERNXIII, you can see my face on it.
-
cool, was curious, i thought i remembered him sending those out to specific people
-
Yup, that’s what he does before disappearing 😅
-
some speculate that dank dark pill and daniel got hits are the same person
-
I'm in this one: https://xchain.io/asset/MODERNII
-
who's in there with you, i see looney, is that 14 year old oliver in the red?
also, looking buff in there Mike -
You missed Shawn?
-
saw him as well
-
still using xchain I see 😂
-
sourced the link using the way back machine
-
And? Why wouldn’t I?
-
Dan worshiping board apes lol
-
Is today February 5th? -
Is this the Official Counterparty Chat or the Forked Counterparty Chat?
-
Or is it is what it is?
-
You enter your comments here and read the reply somewhere else.
Official Counterparty Chat
Public archive of Telegram messages.
- 01 Jan 2024 (25)
- 02 Jan 2024 (17)
- 03 Jan 2024 (32)
- 04 Jan 2024 (83)
- 05 Jan 2024 (37)
- 06 Jan 2024 (24)
- 07 Jan 2024 (603)
- 08 Jan 2024 (1209)
- 09 Jan 2024 (709)
- 10 Jan 2024 (609)
- 11 Jan 2024 (1340)
- 12 Jan 2024 (807)
- 13 Jan 2024 (482)
- 14 Jan 2024 (370)
- 15 Jan 2024 (686)
- 16 Jan 2024 (333)
- 17 Jan 2024 (54)
- 18 Jan 2024 (38)
- 19 Jan 2024 (197)
- 20 Jan 2024 (107)
- 21 Jan 2024 (26)
- 22 Jan 2024 (28)
- 23 Jan 2024 (100)
- 24 Jan 2024 (57)
- 25 Jan 2024 (65)
- 26 Jan 2024 (32)
- 27 Jan 2024 (11)
- 28 Jan 2024 (40)
- 29 Jan 2024 (61)
- 30 Jan 2024 (62)
- 31 Jan 2024 (35)