- 01 June 2023 (510 messages)
-
of course ..what I am getting at is a dust return pub key is needed when using p2sh inputs if you using counterparty in a more traditional way and would like to be able to reclaim your satoshis -
What do you mean? The api won’t let you change it if it’s a p2sh input? -
what I mean is ... if cp is changed to make use of the 3rd output zs a data store it should only be done when using non p2sh inputs
-
it is there to allow facilitate p2sh inputs as they don't have a pubkey it can use by default
-
Ah yes I think it should also be optional
-
few use counterparty with multisig but it's very cool to be able to
-
do dispensers work on multisig p2sh addresses?
-
as in theey the dispenser not the buyer
-
I believe so
-
thanks
- 02 June 2023 (124 messages)
-
In hopes of moving to a beneficial outcome for all communities.
We are willing to pause stampchain src-20 minting until new functionality is ready (in or outside of CP broadcasts for src-20) if the conversation can continue irt a more creative xcp fee structure for stamps and numeric assets. We will also highly encourage other services to pause. We will continue to index src-20 in the current method until the new system is launched. At which time we can select a block where any legacy src-20 trx on issuances are invalid.
The real sticking point for stamps on CP is the xcp fee, if that can be handled in btc to the user and then xcp burned on the backend we can fully support that, and continue forward for stamps in a more cohesive manner. Or perhaps some other creative method. This eliminates the need to get creative to bypass/reduce the fees or be pushed into a fork and divide the communities which mostly have a foot in both stamp/xcp ecosystems. Any xcp related fees on a stamp transaction are a relatively small percentage of the miner fees anyway so this shouldn't be a burden.
Also, No problem hiding 0 asset issuances from public facing venues and we are happy to support purging if deemed neccesary or productive in future iterations of database redesign.
The reality is that src-20 is moving one way or another, and we have no intention of creating (continuing) a rift in the stamps/xcp community over this experiment. If pausing src-20 eliminates that potential burden on all communities it's deemed well worth it regardless of past action. We'll now have time to optimize aws usage to drastically reduce spend as well 😉- almost all attributed to db read/writes in excess during deployment anyway. This is riduculous on all accounts, and was simply shared to shed some light on short term financial ramifications of ceasing production. Certainly something that shouldn't be placed as a burden on CP to attempt to recover. At the very least it shows that we are willing to invest - ideally in much more productive outlets moving forward.
All stakeholders on our side are supportive with this path. It makes no sense that stamps and the artists involved would be held hostage over short term implications of src-20 minting.
On a side note i'm showing approx 7000 trx in the mempool, but the CP mempool table only had something around 2000 at last check, and haven't had time to dig into this. The initial wave has passed and it's prudent to regroup.
now back to the regularly programmed memes which is all i'm here for anyway -
please let us know in the chat once you've turned off the service -
-
Thank you!
-
-
I've posted some CIP29 issues on Github. Shouldn't be a party stopper, but would like these to be resolved before going ahead with the update.
https://github.com/CounterpartyXCP/cips/issuesIssues · CounterpartyXCP/cipsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Did some performance testing.
https://forums.counterparty.io/t/testing-scalability-of-assets-and-issuances-tables/6621/3Testing Scalability of 'Assets' and 'Issuances' TablesI’ve simulated inserting rows into the assets and issuances tables and measured the performance. The initial DB is a real, recent Counterparty DB. The added rows are random values of the same format as real values. Assets Milliseconds to look up a name: The performance is worse than O(n) 😱 Issuances Counting the number of rows for given names. Even worse… Python scripts used for testing. Assets: db_file = 'db_copy.db' #latest Counterparty DB import os dir_path = os.path....
-
good job @jdogresorg on the space -
fyi i’ve been suspended from twitter… waiting for dictator to let me return to the metaverse.
-
what you do? I've never seen you tweet anything controversial. I've been on twitter since 2009 saying all sorts of crazy shit and have never been suspended -
he tweeted that counterparty wasn’t dead
-
-
LOL
-
Hahaha -
-
Just a head’s up that there is presently an SRC-721 mint happening on Bitcoin Stamps. SRC-721 was developed by another team in the ecosystem and is not being minted through Stampchain. That being said, despite the similar names, the 2 token standards are very different. SRC-721 have a supply of 1 rather than 0 and are intended to be used in dispensers. They take full advantage of Counterparty functionality. Just wanted to raise this as they look similar at first glance given that xchain does not render them.
More details here: https://twitter.com/0xderpnation/status/1664671834975895569LinkWe are live for the @AvimeNFT on stamps collection. Generate an anime avatar and stamp it into Bitcoin! All for only $15 To mint you will need to join the discord and follow the instructions. https://t.co/sENUZAx4e4 @mikeinspace @adamamcbride @Stam_Punks @ApeDurden
-
They are still spamming tokens and abusing cp…. Issuing one token just tweaks a crappy model…. This sucks…. Just reinforces need to fee in numerics… damnit… wish this shit coulda been dealt with 4 weeks ago before src-20 bad model was set… but think this is going to just continue.
-
I’m too tired to fight anymore….you guys figure it out… I’ll be blocking these on xchain when I get home
-
I just heard you on spaces saying they are spam if they don’t use Counterparty functionality. These literally do. This was also developed entirely independently.
-
This is cat and mouse…. Still spams a numeric for every mint and transfer…. Cp can handle how they want… I’m done.
-
No it doesn’t. There is no mint or transfer
-
-
Please read up on the spec
-
These work nothing like src20
-
Sure looks like a MINT to me
-
I’m looking at what they are encoding…. Asset for every mint
-
Op=mint != mint operation?
-
Did you listen to the spaces 2 hours ago? Completely different argument then. @jakegallen
-
Maybe this is not bad… to exhausted to figure it out guys…. Done… won’t block til I have time to figure out wtf…. So tired n frustrated n close to breakdown
-
Anyways the reason I announced it here at all was as a good faith gesture because they look similar to src20. Even though this is a completely independent project
-
Not necessarily, don’t assume the worst. Why not invite them to the discussion
-
Educate Vs being defensive.
-
Oh haha you are already here
-
Thanks man… sorry for being defensive… just overwhelmed… really happy with the progress made in last 24 and the cooperation n want it to continue❤️
-
This is super innovative. Out of the box thinking that reduces the cost to mint by 100x.
-
I’d tread lightly,
-
I just went through the process. I think it's a cool concept, and it was my first time signing a tx in freewallet like that. -
Big bonus points for it not being completely absurd and acutally using Counterparty's token system.
-
Sounds interesting. And glad you are engaging in the conversation and trying to understand the issues and address them.
-
Read my next comment. I’m just saying it’s volatile, so be careful.
-
Good way to put it. Probably the first innovation on stamps that’s the opposite of absurd. It’s actually practical
-
Just don’t say the forbidden 3 letters lol
-
-
How it works
-
Yeah I think it’s a great idea
-
Much more efficient than copying the same image bits over and over again in base64
-
A picture is worth 1000 words…. Read spec, looks sane… pic makes it click… thx Mike
-
Thanks for sharing and engaging n building on CP👍🏻
-
I just wish you had held off a couple weeks and we could have incorporated it. Not sure these will be deemed “valid” by the parser.
-
Which is the ironic thing. They appear on xchain but not stampchain
-
What parser?
-
The parser that determines what’s a valid Bitcoin stamp
-
might be a bug as many are getting suspended. or ben.eth army attacked me for vocal criticism. or elon didn’t like y joke. who the fuck knows.
-
Would have preferred real stamps but your call
-
Make them named next.
-
There as real as you want them to be
-
Decentralized protocol
-
Stamp SV
-
Well there is software running and if we make previously invalid stamps valid it messes with our sacred numbers
-
This is the King James Version
-
And I talked a lot of shit about ordinals doing that
-
Hard to walk back
-
Lol
-
Lol no one remembers and/or cares
-
Only one truth
-
Those that do, many respect someone who can change their mind
-
Derp should start over at 1 again
-
Stamps chapter 2
-
Numbers are getting unwieldy anyway
-
I think they way you did it was fine tbh
-
Numbers are annoying, let’s invent something new *using* numbers!
-
dig it
-
They definitely won’t be included on stampchain named
-
Their fake stamps!
-
It’s about time for a new fake protocol
-
Call them etchings
-
stamp sheets
-
dispenser still live?
-
There is not tax on dispensers.
If it’s named, that will help the community from an economic standpoint of XCP holders.
Higher XCP price means more funds for community members to reinvest (donate) in dev.
I can’t speak on the database table -
Sane asset use is goal n this looks sane👍🏻
-
are you familiar with dispenser frontrunning issues etc?
-
asking because you said you’re new to CP
-
A new guy but an OG! Linagee is a part of history.
-
Guys what the fuck is SRC721? -
see here
-
I read the words. What tools do I need? Just freewallet? Are there any services that make it easy to deploy src-721 yet?
-
Lol
-
Derp might be able to assist.
- 03 June 2023 (8 messages)
-
very cool... nice work... I like the having users sign/broadcast their own txs... as it should be 🙂 Also really digging all the explainations that you give on discord and big red letters explaining what is scary and WHY it is scary.... Your doing a great job trying to educate ppl
-
Tiny update on my end. As the fee CIP author i feel ALMOST ready to give the green light. Only missing like 2-3 lines of code to have the fee apply to issuances triggered by sweeps.
Maybe Javier or Joe can add this piece of code?
Im going offline for the weekend. If nothing extraordinary comes up, i will close the github issues on monday and give a 👍 -
Based on the result of discussions the last 2 days and good faith shown by src-20 devs by pausing minting services to move to broadcasts (or something else tbd) I think at this point tabling the XCP fee on numerics and focusing instead on database optimization is probably the best path forward to keep everyone in alignment
-
this is my stance. lets not make this about $XCP price benefits of more burns either (not saying that is the motivation but goes without saying too).
all of the drama mostly was about issues beyond inefficient use of CP by new projects, it seems to me. this would not even be a big issue if CP was not centralized so in addition to finally making improvements to some of the root problems (database schema optimizations etc) we should put some effort into getting this thing more distributed. JDOG cannot be the primary one holding up CP forever and as a result be a centralized force (which he does not want to be). -
It is important to not have CP be a hypocritical platform. It uses Bitcoin in ways that have been deemed over the years as rogue and not inline with the intended design of Bitcoin. Yet all these years it was able to proceed albeit with little interest. Now CP is being used in rogue ways not inline with the intended design of CP. Instead of reacting with a laser-eye attitude, we can be the evolved ones and still vocally discourage stupid and arguably detrimental usages of CP without taking what can be considered the most aggressive and drastic responses and changes to CP.... ever.
regardless, just one supressed voice and a few cents worth of opinion. 🧡 -
No one wanted to get rid of free A assets. Just wanted the spamming to stop.
The only real way to stop spamming would be through price restriction = XCP price so it’s impossible not to mention.
Jdog went out of his way over and over again to try to stop the spam without having to add an XCP fee
Joe holds no XCP basically
Quinten wanted to lower the subasset fee
JP suggested the initial A asset spam fee 0.01
Clearly they could care less about XCP price and that had zero motivation for them.
If you want to point fingers at anyone talking about price, point them at me.
But yes, I do think a higher XCP price is good for a community that is 100% self funded via donations and sweat equity from day 1. -
This is what actual decentralization looks like, it’s not pretty but if you have a common goal it’s possible to find some sort of consensus
-
nah, not pointing fingers. just worth mentioning imo because even I, who has like 2 xcp at this point, can understand how some changes could have a price benefit and its important that decisions have nothing to do with this.
i have followed the discussion and have a good grasp of whats going on. - 04 June 2023 (30 messages)
-
Regarding dispensers: it’s good that they now contain a warning about Taproot addresses on xchain (bc1p). It would be good if they also warned about using 3 addresses. While 3 addresses will receive the dispensed asset, they are effectively “trapped” until such time that Freewallet and/or Counterparty support addresses starting with 3.
This seems to be specific to xverse (which neither supports Stamps nor do we promote). But with an increase in new users, it’s reasonable they might think that a prompt to “send bitcoin” would mean any address type (unless otherwise stated).
Is there a plan to support 3 addresses at some point? -
they work for p2sh addresses, but like you said you’d need a wallet that supports it, probably makes more sense to say “only send from a counterparty compatible bitcoin wallet” or something like that
-
I don't think we should break the toys. We should be building new toys and tooling for said new toys. Who knows what's actually valuable?
-
-
@WTHAuctionHouse Session Two is commencing in one minute! -
Oh sorry about this earlier, was going super fast thought it was main group
-
Meanwhile… is this accurate?
https://twitter.com/nftnow/status/1664775281574281218?s=46&t=O9S84Q5c-hYElZg9yJRCWQLinkLastly, meet SRC-20, or STAMPS. This Bitcoin standard was created by @Stampchain and provides an extra layer of decentralization. Unlike BRC-20 tokens, SRC-20 transactions cannot be removed from Bitcoin. Now that's secure. 🔐
-
BITCOIN STAMPS
Unprunable UTXO Art, Because Sats Don’t Exist.
-
We made it all up. Turn out the lights. Go to bed. Wake up in a field of grass under a blue sky and forget it all.
-
-
I love the "made up" argument as if that doesn't apply to literally everything. Bitcoin was "made up" too. Shared hallucinations make the world go round.
-
I think it does muddy the fact that there is an actual technical implementation that people actually put time and thought into building in such a way that it “just works” well enough so that we can then add the “it’s all pretend” meme
-
Bitcoin creates the solid foundation to make things up on
-
Bitcoin Stamps: The Realest Fakes around.
-
That description is surprisingly accurate
-
Its funny because there has been zero contact with anyone at blockchain.com, so they came up with it all on their own including the description.
-
https://xchain.io/tx/74c31846adcce7e8cbad44b5c7162cce3b03d74305fe9ae26b61bfa34a1d8bc6
assetic.io for more details on A.S.S.
Yuge thank you to JDog for integration of custom A.S.S viewing UI within xchain
Had some lols getting this out of the door in a week after joking in a DM -
Asses can have two cheeks (or just one) spreading the second cheek will allow you to conceal the ASS initially users can then push a button to expose that ass.
example http://xchain.io/asset/burnedass -
Asses can also have a optional crease, a crease is handy for numerics that youd like to title or for named assets that would like some additional context
example : http://xchain.io/asset/badonkadonk -
what makes this different from say an easy-asset using json to reference a hash, is that this hash is logged in the btc txs when providng the description.
-
-
-
-
Love the concept, love the delivery
-
🍾
- 05 June 2023 (95 messages)
-
Joined. -
Joined. -
Joined. -
Joined. -
wow look at all these new developers!
-
you can spin up a fednode with 3 like 3-4 commands.... bitcoind will take about 12-24 hours to sync all data.... addrindexrs will take 1-2 hours to build the full index once bitcoind is fully synced.... once THAT is done, then counterparty-lib starts up and downloads a bootstrap database....
-
if you just want to get at a quick CP database to look at... you can download the bootstrap directly
-
-
I believe all of these ppl are real
-
still tracking down an issue in the bootstrap with a single tx that parses slightly different based on bitcoinjs-lib version.... but, otehr than that, bootstrap should be good 🙂
-
top two smartfast2222 and ALI are reported socks, bottom too probably also
-
usually "A" are spam accounts :)
-
also... if you want to get access my counterparty data in a mysql database... there is counterparty2mysql.... I haven't updated the bootstrap in a few months... but, another option to just grab a database, honk it into mysql, and play with the data 🙂
-
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
-
numerical asset? -
lol
-
its like a numeric asset but you sing it
-
Good, s/he's here to learn, welcome 😉
-
I shared dev channel link in main channel.... if we dont share, we seem closed off... if we do share, we get lots of non-devs in here..... as long as we can keep the chatter here focused on dev, should be fine... but yeah, more ppl will require more ppl to help keep topics focused on dev.... puhleeze.. 🙂
-
lately we had a lot of zero issuance numerical asset spam
so now we have a CIP 29 proposal to introduce fees to reduce spamming of numerical assets
but it's not being implemented just yet
https://github.com/CounterpartyXCP/cips/blob/master/cip-0029.md -
you just proved you are
-
Ser, he was giving you context of my joke out of context based on this channel
-
New users... please remember to read the PINNED message... including the content policy. https://github.com/CounterpartyXCP/Documentation/blob/master/Counterparty_Content_Policy.mdDocumentation/Counterparty_Content_Policy.md at master · CounterpartyXCP/Documentation
Official Documentation of the Counterparty Project - CounterpartyXCP/Documentation
-
We speak respectfully to one another here.... or we get a warning, then get put on timeout... please respect the rules and dont make us have to be babysitters 🙂
-
-
🤣
-
Hi guys with regards to the dispensers , wouldn't it be better if the dispensers receive BTC from a CP btc address then once confirmed the assets get sent to the buyer. If there is a duplicate buy then the funds get returned to the the person who sent too slowly -
tons of scams happening now with people buying and then the transaction being front run
-
-
that, unfortunately, is a weakness of dispensers, there is another tx type in counterparty called btcpay that can mitigate this tho it requires two txs
-
Perhaps review the proposed solutions that have already been discussed.... we are aware that there is an issue... and there are multiple solutions being discussed.... so, please familiarize yourself with the discussions.... we welcome suggestions here, but prefer ppl do some reserach to make sure they are aware of previous discussions... so we can all avoid re-hashing out the same conversations again and again here
-
I plan to implement dispensers into BTNS and play around with a few of these proposed "solutions" to dispensers.... to see what works, what doesn't, etc.... but in CP, we are still in "discussion" mode about how to handle dispenser issue the "best" way.
-
My two cents (fwiw -- not much) is that a lot of the issues could be mitigated without actually making a change to the dispensers at all. We've previously discussed seller authentication. There are also some helpful tips on the dispenser pages now (like don't send from Taproot address) which is good, however, I think a redesign of the entire template could drive home the potential issues for users without overloading them with messages they won't read. I may mock something up a little later to get some feedback.
-
mock it up!
-
dispensers are a double edged sword but mike is right that trusted dispensers work extremely well, for example when an artist creates a dispenser to sell their own work they have no incentive to front run or hold on to any funds received after a dispenser has closed
-
It also will help to direct the complaints/tears out of the Counterparty channels towards the actual seller who may be able address the issue.
-
yep
-
GitHub - jdogresorg/CryptoMessages: A bitcoin-based secure address messaging system
A bitcoin-based secure address messaging system. Contribute to jdogresorg/CryptoMessages development by creating an account on GitHub.
-
Working on building out a messaging solution... so wallets can send messages to one another... buyer can contact seller directly, leave a message, etc
-
not ideal... but SHOULD help in this case with dispensers... and helpful in some other cases... just gotta find time for Javier to finish and to integrate into freewallet... </end info> 🙂
-
What about an insurance option in freewallet for double pays the insurance price will be the cost of another tx
-
need to consider how counterparty works and that fact that counterparty is aware of bitcoin but bitcoin is not aware of counterparty, because of this it is not possible to escrow bitcoin on the platform
-
btcpay actually works really well for sales its just never had a great UI
-
because there is a gap between the 1st and 2nd tx, the 2nd can’t be sent until the order match is confirmed
-
Thanks for sharing all this documentation. I have read it all I think there are some options being discussed that could solve the current problems with dispenser scams. I´ve put up a form to get notification on Scams. I can share all that information as well as my POV on the issue (i think I´m the one with more data about whats going on and where). Should I writte all that here? https://forums.counterparty.io/t/cip21-dispensers/5488/11 -
Please write up your thoughts here or in the forum post but pls setup any tracking of data on ur own…. Once I have some time can prolly integrate into xchain when it makes sense👍🏻 nice work n thx for the offer to cooperate❤️
-
-
niceee!!!
-
I´m going to prepare this to share it ASAP ;)
-
@reinamora_137 https://i.gyazo.com/ee1c8b9ade64ed4a6d98ff27a06b3265.png ... Trying to add support for "Bitcoin Stamps" back to xchain... but seems the URL which was previously working to get a list of all "Bitcoin Stamps" is no longer working.... If you or your community want "Bitcoin Stamps" green banner back on xchain, please get this file working again... or point me to a SINGLE request I can make to get a list of all stamps.... not interested in writing more code to iterate through results, etc... pls make it easy for me to support Bitcoin stamps, as it was before (single file request), and I will work on re-enabling the banner 🙂
-
Feel it is important to get the green banner up and in freewallet/xchain so ppl know what is and is not an official Bitcoin Stamp card (will still scrub src-20 from having the green banner, but fine with all other stamps having green banner)... hopefully cut down on scamming a bit 🙂
-
all I really need is just a list of the asset names in a JSON file... if that helps 🙂
-
great to hear, appreciate it. Do you have a list of IP's I can whitelist? We have implemented some protection on the website to reduce costs. Could implement a lightweight version or an API call specific for what you need in the future.
-
sure... will DM you the IPs for my dev machine here (testing) and production machine (where requests will come from)
-
FYI... I will only be making this request during dev/testing... and then ONCE per day in production... so load on your server should be minimal 🙂
-
is stamps.json -
yeah... the format changed slightly... I tweaked the xchain parsing script.. and @reinamora_137 got me access... been parsing stuff for the past couple hours... should be caught up soon 🙂
-
-
-
Green xchain banner restored
-
Hello everyone,
As I commented a few hours ago in this chat, I wanted to make a summary of context to include everything that has happened in relation to the recent scams in the dispensers, taking into account the conversation in the CIP21 - Dispenser to propose some possible solutions, which have already been discussed here and others that I put on the table.
In order not to flood the chat I have preferred to do it in a separate document, but let me know if you want to incorporate it to CIP21 or continue the conversation here. -
Joined. -
anyway you could host as a google doc or make a forum post?
-
also have you seen this? https://robotlovecoffee.wtf/xcpRobot Love Coffee
Onboarding Videos for Creators and Collectors on XCP
-
yeah can share adoc np
-
yess, but not sure if that process can handle current demand of sellers. We had a peak of 13k users daily... i suppose that at least 30% are going to be sellers in 1-2 weeks.
-
about this point: -source address is not associated to a known scammer address.
-
what happen if scammers do a multisend to all this wallets.. or the new ones getting verified.
-
It´s better than nothing but I see that it cant scale IMO
-
this list is maintain by Niftyboss you migth want to connect if you wanted to know what else they can provide -
it is a known list of good dispenser for xcp
-
that they track
-
-
You guys are Legends im sure some solutions can be found.
-
I've been using dispensers for two years without any single issue or issues by anyone I know
-
But the ecosystem have grown a lot recently... So scammers have come to scam newbies
- 06 June 2023 (133 messages)
-
Joined. -
🙏
-
As promised, here is my mock-up for dispensers that might help address common issues.
I think a lot of the present issues could be addressed with appropriate messaging and, perhaps, authentication of sellers. -
A summary of possible dispenser solutions. https://forums.counterparty.io/t/solutions-to-rugspenser-problem/6623Solutions to "rugspenser" problem
Attack vector: Scammer detects incoming buy and immediately sends another buy transaction with a higher fee. The scammer’s tx gets priority and the legit buyer loses his bitcoins. Possible solutions: 1. Pre-payment before full payment This requires a protocol change. The logic is simple. If less than a full dispense is detected, allow up to 12 blocks for the second tx. Perfectly safe as the protocol keeps the token on escrow. The buyer, if not trusting the seller, can thus make a tiny pre-pa...
-
Tnx for posting detailed report btw. Made me write the forum post so discussion can continue there.
-
3 addresses e.g. p2sh multisig are fine just not the wrapped segwit type so it needs making clearer that multisig p2sh is fine but
Pay To Witness Public Key Hash Wrapped In P2SH are not -
Authenticating sellers is not a good solution IMO. The protocol should provide the safety, instead of social controls like KYC’ing sellers. Just my $0.02 🤔
-
Call it what it is a dispenser with some contact info
-
Thank you! I will do there
-
I agree. This is sort of meant as a "stop gap" measure for current dispenser tech
-
Its a balance between accuracy and talking over the heads of your audience. Some (all?) 3 addresses don't work in Freewallet, so they effectively don't work on Counterparty.
-
It's not hard to talk over heads of users they think xchain hosts dispensers 😂
-
Yup. They don’t know the difference at all. You could always have a “click here” for more advanced details. But in terms of what they understand: “starts with 3” seems like something they would “get”.
-
But if no wallets use p2sh what’s the point of the warning?
-
Cuz retards use exchange accounts or wallets that no one told them to use. Yes it’s “user error” but maybe we should protect the retards a little too
-
But how is this gonna help them in that regard
-
It might help you! No more complaints in CP chats
-
In my experience, the more words you put on the screen the less likely users are to read any of the words
-
Agree
-
So just put a big “must use a Counterparty-aware wallet”
-
Rather than a bunch of details
-
Sure. That’s at least better than the current. However… isn’t RPW a CP aware wallet? It’s not gonna work with bc1q
-
I think details are good too but they could appear after clicking a “more info” button or something
-
It just won’t let you send to that
-
Nothing will break
-
Except their hearts…
-
Also that’s rarepepewallet, rpw.wtf works just fine with bech32
-
Lol if the goal is to make sure they don’t send funds into a void then not sending prevents that
-
I agree, this with a modal or link to the full info will be perfect!
-
You have a very valid point re people not knowing the difference ... I doubt they will educate emselves either ... they just reeeeee louder when it doesn't work and no one wants upset users
-
Yeah likely true. Just wanted to get some discussion going with the mock-up as I think there are some obvious things that could minimize issues, but yeah, ultimately people don’t read.
-
they buy and then complain... or buy and then read...
-
but for the ones dealing with complains it´s much easy to deal with if they have warnings and we cant point to them that they didnt check the warnings :)
-
Exactly. It’s a liability thing. You can shift it back to the user and say “look you didn’t read”. Rather than complaining they’ve been defrauded by the blockchain
-
This looks decent. thanks for mocking this up. ❤️
Pls write up a trusted dispensers api where I can pull a list of dispensers that are “trusted”…. This solution requires me to do even more work…Overworked already… and STILL working on my own dime this year…. If this is important to the community… please build it… I am happy to integrate once it’s easy n makes sense…. but not down to take on yet another burden for CP… ecosystem needs to grow, not keep throwing more on my todo list.
Supportive of ppl not being scammed, but not my responsibility to educate all the new users being onboarded…. I do my best in freewallet and xchain… users don’t read text so more red/greeen text won’t help cuz 99% won’t read.
IMO education should fall on the projects onboarding ppl… they already benefitting from the “free” explorer, wallets, ecosystem…. Maybe build what you want to see… I have👍🏻 -
I thought trusted dispensers were the solution last year… don’t feel that way anymore… prefer we fix on protocol level n eliminate need for any “trust”….
But am happy to finally see ppl taking dispensers issues serious… just sucks we’ve had these issues for years n NOW it’s an emergency🤷🏻♂️😜 -
A simple pre solution may be just creating a telegram room for trusted dispensers and having the telegram user post the dispenser address in that telegram room.
Then anyone can search telegram for that address to verify its X telegram user -
It’s certainly not even a good solution, but is better than nothing and can be done now
-
an protocol level fix is best..but until,such time ... Here is a idea .its just a idea I not looking for the job lol but hows about a community held multisig that people can deposit to so it can be seen on chain they got skin in the dispenser game
-
so a 1 btc dispense needs a 1 btc fee ? .. not happening
-
I think he was joking
-
That’s an absurd idea lol
-
Is BTCpay a viable solution to dispensers if tweaked in a way that offers a smooth user experience?
AFAIK, dispensers were created primarily to solve the 2txs required using BTCpay. But to me, using a decentralized way for exchange far outweighs solving the 2txs issue. -
So is burning BTC… but it’s the norm around here…. Absurd is relative😜
-
We have build guides in Chinese, English and Spanish and pointed to Robotlovecoffe and phunckins for tutorials on how to use it.. but I think we have to create more guides with all the warnings. I´ll add them to my to do list.
-
Best solution is XCP and the DEX tbh 😂
-
I am with you here. Going the path of verified sellers it´s going to bring a ton of work... just from our collection we have over 200 holders that would like to sell.
-
Yes I think this might be the best way at least in the short term
-
Moar red scary text n green soothing words 😜 def appreciate the efforts your making to solve this issue n educate n protect ur community members❤️
-
But need to leave wallet open to sign?
-
Yes as soon as you get a confirmation you need the second tx, you don’t need to leave wallet open persay but you need to be prepared to fill the order once it does confirm
-
Yeah that's what I meant by making it more user friendly. At its current form it's clunky. Not sure of the technical challenges though.
-
The framework that the original rarepepewallet was built on was called btcpaymarket
-
And the whole purpose was to make btcpay easier
-
the current system just needs some tweaking , the first broadcast message"intent to buy" should be confirmed with a certain amount of blocks , if not confirmed then go to the next broadcast tx
-
There’s still a risk if you pay too low of a fee that it doesn’t confirm within 20 blocks
-
You’re describing btcpay
-
this should reduce scams as long as people use a high enough fee
-
GitHub - loon3/btcpaymarket: Buy and Sell Counterparty (XCP) Assets with Bitcoin
Buy and Sell Counterparty (XCP) Assets with Bitcoin - GitHub - loon3/btcpaymarket: Buy and Sell Counterparty (XCP) Assets with Bitcoin
-
What's the outcome should this happen?
-
Your bitcoin is sent and you don’t get assets
-
Same logic as dispensers “if people pay a high enough fee”…. Can’t depend on that… cuz ppl be cheap
-
The difference is you can’t get frontrun with btcpay
-
Also, why 20 blocks? Can't this also be tweaked?
-
That’s what the devs chose at the time
-
It could be changed but would
require a consensus update -
If people pay below the current fee for transactions then thats their problem , all im saying is your system see's a unconfirmed transaction then give that transaction queue position 1 and allow it say 6 blocks ( 1 hour ). If someone pays with a higher fee his transaction wiill be 2nd in a queue.
-
I can do a writting about this for ussers to understand the full process. I f its already a guide about this I´m not aware of.
-
The mempool cannot be used for Counterparty consensus
-
Everyone’s mempool is different
-
DEX BTCPay Overview
---
1. Place order to sell something for BTC
2. Place order to BUY something for BTC (BTC Buyer)
3. BTC Buyer has to monitor for order match
/api/order_matches/{address}
4. On order match generate BTCpay tx
create_btcpay using the order_match_id (order_match_id = order1TxHash_Order2TxHash)
5. Send the BTCpay transaction with a high miners fee to get processed in next block
6. Wait for btcpay tx to get confirmed and verify you got tokens from order (optional)
Freewallet DEX BTCPay code
---
checkBtcpayTransactions() - monitors for order matches and adds to processing queue
https://github.com/jdogresorg/freewallet-desktop/blob/master/js/freewallet-desktop.js#L898-L961
processBTCPayQueue() - processes any BTCpays that are pending in queue
https://github.com/jdogresorg/freewallet-desktop/blob/master/js/freewallet-desktop.js#L1042-L1069
autoBTCPay() - Handles generating/signing BTCpay tx
https://github.com/jdogresorg/freewallet-desktop/blob/master/js/freewallet-desktop.js#L1072-L1105
cpBtcpay() - Handles making request to CP API to generate BTCpay tx
https://github.com/jdogresorg/freewallet-desktop/blob/master/js/freewallet-desktop.js#L2646-L2679
createBtcpay() - Handles making request to CP API to generate unsigned tx (generic function)
https://github.com/jdogresorg/freewallet-desktop/blob/master/js/freewallet-desktop.js#L3064-L3081freewallet-desktop/js/freewallet-desktop.js at master · jdogresorg/freewallet-desktopDesktop wallet for Win/Mac/Linux which supports Bitcoin and Counterparty - jdogresorg/freewallet-desktop
-
No guides that i'm aware of... but this should get ya pointed in the right direction if you wanted to work on BTCPay DEX integration 🙂
-
perfect, thanks!!
-
Will try to do a step by step guide and point to all this resources.
-
-
To be on the safe side.
. 6 blocks to confirm order match
. Some miners may block btcpay
. Sudden run of blocks before tx relays
. Opportunity to increase fee if falls behind in mempool -
Another thing to be aware of when using BTCpay is sellers aren't guaranteed a complete divisible asset sale. Buyers may partially fill the order leaving the seller with fractions.
-
yep same with dex
-
People buying 1 satoshi of a Lordkek was how some people learned this BITD
-
DeX is used but needs XCP for single tx asset transfer unless doing direct asset a asset b swaps
-
XCP is essentially the reserve currency of CP.
It’s the escrowable asset of CP backed by burned Bitcoin and utility.
The dex is fantastic, I think a better UI is all that’s needed and the willingness to buy and sell for XCP. -
It doesn’t get rid of the trusted dispensers dilemma, but it narrows it down to a single asset.
-
You could display Dex orders like dispensers for XCP, add an order/sell button and done.
-
xcp is burned bitcoin ... be nice if people understood that
-
yup... could be a beautiful experience if ppl could get over their whole "XCP is shitcoin" mental barrier.... tho, prolly wont happen til we get something like a USD backed asset (ie TETHERUSD, etc) ... then masses are "comfortable" cuz "shitcoin backed by USD"... ppl ok with mental gymnastics to make USD backed shitcoin OK... but BTC-backed "shitcoin" XCP is "bad"... ppl are weird 🤷️️️️️️😛️️️️️️
-
Imagine if it was never called XCP. bBTC (Burned Bitcoin) might have been perceived differently.
-
BBBTC
-
FIREBTC 😛
-
the extra B is for BYOBB
-
Interesting, never thought about that
-
ZombieBTC
-
ZomBTC
-
Hey, XCP-20 was just a rebranding of Counterparty and seemed to work.
-
now we getting somewhere
-
well XCP was the first asset to use XCP-20 technology
-
BBC burned Bitcoin coins
-
LOL.... nope... not holding BBC in my wallet bro 😛
-
Someone should A/B test it... put out an explorer that refers to XCP as some variation of "Bitcoin" and see if perception changes.
-
Just pretend its a drivechain
-
Shadow Bitcoin soundz cool ... could be a fun name to try out, but its just gonna create more confusion for the uneducated
-
The first Drivechain! With bBTC pegged Bitcoin!
-
hahaha its not pegged tho
-
one way peg
-
it would be if there was an open burn
-
so its not even a one way peg
-
Joe, words don't matter...
-
lol
-
Couldn't we do CP atomic swaps pretty easily with a new message type and PSBT? CP API generate a tx to swap A <-> B .... have either party sign the tx.. broadcast... once mined, swap occurs... single tx.
-
no 3rd party preferable
-
There we go...
-
quite flattering, all the recent innovations and talk about things that I was getting into two years ago. It is clearer to me that i should really try harder to follow through with my projects until they are launched, lol
#1553789
the main drawback with a burnt peg is the community as a whole needs to accept the concept. I believe that although the burnt value could be pegged, the market value will end up being less. There are other advantages tho, like actually having a fungible bitcoin for once, lol. -
Damn do I like XCP but this looks very good
-
Atomic swaps with pbsts would be very cool ...
There is no 3rd party, no front running, no just p2p asset transfers
It would need a psbt tx decoder that also decodes and shows the CP data very clearly
One problem is people can claim to own a asset .. generate a pbst to swap it and then move the asset .. before pbst is finalised and mined so some sorta escrow would be needed .. so still going to need 2 on chain txs but stops dispenser front running .. Great for higher value assets ... dispenser still good for lower value and not single issuance assets -
i think we could do psbt atomic swaps in the same way openordex swaps work to trade ordinals
-
FYI... inviting windsok to CP dev (cant believe he is not in there already).... he did a bunch of work on the unit testing stuff last year.... got most of the test working
-
Its hard to bait n switch a sat that does not exist
-
seller uses a dust input and an op_return output with the send message data in there and adds an output with the sell amount to be filled with buyer input
-
Joined. -
IMO one thing that CP needs is unit testing to be working... so we can do dev work and do some basic testing of functions without having to manually test every function of a feature.... @windsok did a bunch of work last year (unpaid, cuz he loves CP) to get the CircleCi automated tests working again... got us like 95% of the way there.... Funding him to finish off the CP unit testing on counterparty-lib would go a long way to help improving CP dev experience and make us able to test and move on releases faster 🙂 #justsaying
-
Is there a way in freewallet.io to export the list of all the addresses in wallet? I have many addresses and dispensers, and its a pain to go and note them down one by one for recordkeeping
-
NO, there is no way to export a list of all addresses
-
Sorry, just realized that this is dev chat. I'd ask questions in the main chat in future.
-
Any auctions that I can apply to sell my collection? It’s important
- 07 June 2023 (3 messages)
-
auction services?
-
It can be vaulted then auctioned on OpenSea. What’s in your collection, and why the importance?
-
Im good now I think.
- 08 June 2023 (1 messages)
- 09 June 2023 (6 messages)
-
seems to be up fine here... https://i.gyazo.com/de7f0bbdd944b33f174a5fcd240d262b.png
-
platform.counterparty.io is always good to check
-
Just posted in the new github discussion forum https://github.com/CounterpartyXCP/cips/discussionsCounterpartyXCP/cips · Discussions
Explore the GitHub Discussions forum for CounterpartyXCP cips. Discuss code, ask questions & collaborate with the developer community.
-
Technically it is not very difficult to add A names or 1-3 letter names
- 11 June 2023 (33 messages)
-
I found (by mistake) it's possible to send yourself btc xcp and other assets .. I opened a github issue
-
Curious why this is an issue? -
it's wastes database space .. the end result is more records for no additional information
-
a btc tx shouldn't have same recipient twice
-
Sending yourself BTC isn’t a way to consolidate UTXOs?
-
not if your sending it to yourself and getting a change output
see the json strings I posted on github and the transactions that cp api constructs from them -
easy fix is to prevent sends when source and destination are the same
-
This is probably more appropriate for a discussion than an issue.... I dont feel that sending an asset you own back to an address you own should be prevented (this is normal and happens all the time)... If you want to change that behavior, lets have a discussion about it.... IMO this belongs in a discussion not github issue. 🙂️️️️️️
-
CounterpartyXCP/cips · Discussions
Explore the GitHub Discussions forum for CounterpartyXCP cips. Discuss code, ask questions & collaborate with the developer community.
-
so I can split 1 XCP into 100 million records of 0.00000001 xcp .. my balance remains 1 xp but the database now have 99 million 99999999 extra records
-
in your scenario... you would be paying tx fees on 100 Million transactions
-
also a btc tx with same address for 2 outputs is not right
-
btc tx fee on a tx is "anti-spam" mechanism enough IMO.... this isn't a huge issue for me... but, doesnt' seem like we should PREVENT this behavior... if someone wants to do it (like I do all the time to speed my txs up)... they should be able to
-
yes ... but why allow sends when source and destination are same ?
-
fair enough to another address you own but sending assets to self is not usual
-
lets play out your scenario... we prevents sends to self... now instead of me just doing an XCP send to myself with a high fee to speed up the tx.... now I have to go off and manually create a tx or do somethign ELSE other than what I have been doing to just use CP how I want... TLDR... your throwing up an unnecessary barrier... SHOULD ppl be sending things to themselves in a perfect world at the same address? No.... but we dont live in a perfect world.. and being able to quickly send an asset from myself to myself with a high tx fee is an EASY way to confirm my tx.
-
glad you found the "issue" so you can avoid it for yourself if you dont want... but I like the feature and use it pretty often to force txs to confirm 🙂
-
I appreciate btc tx fees are anti spam mechanism when it comes to spamming database with fractions of a divisible asset being sent to same destination as source .. but why allow cp api to create a tx with 2 outputs for same address..usually that is prohibited
it's not sending to self to speed up.. you already possess the asset .. its when source and destination are identical .. not moving your zssets between addresses -
hence more discussions... not opposed to removing the ability of community consensus wants it gone.... not stuck on it... but dont want to call things an issue unless they are not working as designed... in this case, its working as designed 😛
-
cpfp with btc is cool,I use it a lot
-
you can still cpfp a send if source and destination are not identical
-
but if you already posses the asset and send to self cpfp is not gonna help as your balance remains unchanged
-
pls create a discussion for it and let some others weigh in.... if consensus is that we want to prevent people from sending tokens they own to addresses they own (ie, prevent them from using assets how they want), then that is fine... but needs more discussions before we just call it an "issue"... IMO issues are things I can just go in an fix.... this is not an issue but a design decision you disagree with, so should be more discussions.... if ppl want it, i'm cool with it.. not a big deal... just seems unnecessary
-
it's not address they own .. that is a mis understanding of the issue
it when source and destination are identical -
Just to check discussions are now done here in the cips repo ? or should it be on the forum, ?
-
IMO conversations can start here... but they should be captured on github discussions and talked out before becoming an issue or a CIP.... we have devs spread out.. some on forums, some in here, some who refuse to be in here and only use github, then complain that everything isn't talked about on github..... tough to make everyone happy... doing our best here... Github discussions in CIP repo is proly best place to get feedback on ideas and such... as well as discuss here 🙂
-
OK I understand .. will delete my issue and open thread in cips discussion
-
Thx bro... I updated the pinned message to link to the discussions repo 🙂
-
no worries I started a discussion on the send to source 'issue' znd I opener a discussion on public keys in enhanced asset json
-
I closed my issue couldn't seem to delete but feel free to remove it as a admin
-
Require supply to be issued in first numeric issuance · CounterpartyXCP/cips · Discussion #91
I’ve been thinking about ways to limit what I consider “abuse” of numeric assets. Named assets and Subassets pay a small amount of XCP as an anti-spam mechanism. Numeric assets have no such XCP ant...
- 13 June 2023 (1 messages)
-
Asset Issuances paying only BTC · CounterpartyXCP/cips · Discussion #92
Currently in order to issue a Named asset or Subasset, an XCP anti-spam fee is required. One of the primary complaints I have heard over the years is that "Counterparty requires a shitcoin (XC...
- 15 June 2023 (14 messages)
-
It´s great! Will answer my pov there.
-
done
-
will this work for dex too?
-
I saw this info about selling assets in dex using BTC. Is it correct or outdated?
-
Active orders and BTC Pay
Note that BTC Pay is available only in the CLI and API.
If your order was to sell BTC, you will still lose the fee_provided (by default 1% of BTC order size). This is done so that the DEx does not get flooded by orders from users who are not serious about concluding their matched orders with payments.
If your order was to sell XCP or other Counterparty-based token for BTC, you will lose 0.002 + 2 * 0.00078 BTC (one transaction + 2 escrow fees).
On the far right of the second image above you can see that your offer to sell (or buy, as the case may be) will remain active for approximately 11 days. That is a rough estimate for the time required for Bitcoin to add 2,000 blocks to its blockchain. That is the current default order expiration time and it can be set on a per-wallet basis in Settings > Default Expiration (BTC Sell). It is not recommended to change this to a much lower value. Because the order was broadcast at block 321478 (screenshot 1), unless it gets matched it will expire 2,000 blocks later, i.e. at block 323478 (screenshot 2).
Once a BTC Sell order has been matched, it cannot be cancelled any more. Then BTC payment (BTC_Pay) has to happen within 20 blocks of the bitcoin blockchain (counting from the block the order entered the blockchain) and it is not possible to cancel it. If BTC_Pay does not happen, XCP (or other Counterparty-issued) tokens are returned to the DEx order pool for further order matching until order limit (by default, 1,000 blocks, if the defaults haven’t changed in the meantime) has been reached.
For example you make a Sell XCP order and 5 blocks later it is matched. By block 25 (20 blocks later) the other side has not paid so your XCP tokens are returned to the DEx matching pool where they can stay up to 2000-25 = 1975 blocks or less (should they be matched and paid, or cancelled by the user).
Your placed order will also be visible on the blockchain (example using the now defunct Blockscan.com is shown below, but you can use xchain.io 1 instead). Escrow amounts seen are redeemable fees that are separate from transaction fee (0.002 BTC) which is not shown here but it can be observed in an explorer (look for other transactions that happen at the time of placing the order). -
found it here: https://forums.counterparty.io/t/when-is-a-dex-order-considered-active-and-how-can-i-cancel-it/1180When is a DEx order considered "active" and how can I cancel it?
If you place order on the DEx, it is not considered active because it first need to enter the blockchain, which may take couple of minutes. Once that happens, you will get a notification that your order is active and you will be able to see that in your wallet’s history (select correct address from drop down list in History pane). At that time you will also be able to see your offer (order) under Exchange > Open orders. As long as your order has not been matched, you can click Cancel to...
-
Btc on dex works… my proposal doesn’t include the Dex
-
Is the fee accurate? 0.002 + 2*0.00078 BTC?
-
Multisig dust fix by jdogresorg · Pull Request #1244 · CounterpartyXCP/counterparty-lib
It has recently been discovered, that due to a misleading summary, Counterparty transactions have been paying 7800 sats for years instead of 780 in multisig transaction outputs. The original post i...
-
I would like to merge this update ASAP and get the CP API servers updated.... Will do so in the AM unless there is some valid objection to lowering the dust level from 7800 to 1000... feel it is important to reduce this cost sooner rather than later, especially with so many ppl using multisig now (stamps)
-
FYI I just made the following updates :
- Merged Multisig dust fix PR (reduces dust from 7800 sats to 1000)
- Created updated mainnet/testnet bootstrap images for 9.60.2
- Updated CP API servers to use the above multisig dust fix
- Downloaded the new bootstrap image on CP API servers and validated integrity
Downloading mainnet bootstrap DB...
[2023-06-15 15:23:54][INFO] Running v1.1.5 of counterparty-server.
Downloading database from https://counterparty.io/bootstrap/counterparty-db.latest.tar.gz...
Extracting to "/root/.local/share/counterparty"...
Cleaning up...
[2023-06-15 15:26:05][INFO] Running v1.1.5 of counterparty-server.
[2023-06-15 15:26:05][INFO] Running v9.60.2 of counterparty-lib.
[2023-06-15 15:26:05][INFO] Acquiring lock.
[2023-06-15 15:26:05][INFO] Connecting to database (SQLite 3.24.0-r1).
[2023-06-15 15:26:05][INFO] Checking database foreign keys...
[2023-06-15 15:26:14][INFO] Foreign key check completed.
[2023-06-15 15:26:14][INFO] Checking database integrity...
[2023-06-15 15:27:52][INFO] Integrity check completed.
[2023-06-15 15:27:52][INFO] Connecting to backend.
[2023-06-15 15:27:52][INFO] AddrIndexRs connecting...
[2023-06-15 15:27:52][INFO] Connected to AddrIndexRs!
[2023-06-15 15:27:52][INFO] Starting API Server.
[2023-06-15 15:27:59][INFO] Resuming parsing.
[2023-06-15 15:28:44][INFO] Mempool cache initialized: 5.06s for 20,000 transactions
[2023-06-15 15:28:44][INFO] Ready for queries. -
The counterargument would be that a low dust amount renders redeeming uneconomical
-
these outputs are still able to be redeemed... same as they were when they are at 7800 sats... except now it costs almost 10x less to encode data.... IMO "uneconomical" is a personal decision... i'll still be collecting all my dust at 7800, 1000, and 546 sats 👍️️️️️️
-
Uneconomical in the sense that the transaction to redeem them would necessitate at least 546 sats per output (and probably more)?
- 16 June 2023 (3 messages)
-
At what sat/byte rate is the fee equal to the amount redeemed?
-
I did a quick calculation. 1000 sat dust is economical to redeem if fee < 7.8 sat/B.
Pls double check result.
https://github.com/CounterpartyXCP/cips/discussions/93Break-even fee ratio for multisig redeem · CounterpartyXCP/cips · Discussion #93This transaction redeemed 5 multisig outputs of 7800 sats each: https://blockstream.info/tx/58ecdf02ac1d299b5d59d81f92c22ab1195377a60f13ae8d080a0d7a7ddb8157 From a total dust amount of 39000 sats, ...
-
Hello i did a bit of a writing on how to use the DEX for buying and sell (using BTC), this is a draft to the tutorial. I used all the resources I found + a personal exercise of buying and selling. Can you check if you find anything wrong? Also for doing it with BTC, its that using BTCpay? if thats the case how can I do this? (Confirm the payment: Click on the notification, then click "BTCpay" to complete the transaction.) Thank you all! https://medium.com/@rarestamp/counterparty-dex-tutorial-trading-tokens-and-using-btcpay-d539cfed68c
- 19 June 2023 (13 messages)
-
I´ll share it also in a docs https://docs.google.com/document/d/1Rz3bENkFJ7YcQN_35KUCtWBMjaFFVZTF3P_DaFNVd6k/edit?usp=sharingCounterparty DEX Tutorial: Trading Tokens and Using BTCpay
Counterparty DEX Tutorial: Trading Tokens and Using BTCpay Introduction Counterparty is a unique layer built on top of the Bitcoin blockchain, allowing users to create and trade any kind of digital token. In this tutorial, we will guide you through buying and selling tokens on the Counterparty DE...
-
I tried doing a dex trade using BTC but didnt work
-
Joined. -
I might be doing something wrong
-
I would like to share in the guide how to do it
-
Joined. -
hey guys. Anyone getting this error response from the cp API today?
{
"error": {
"code": -32000,
"message": "Server error",
"data": {
"type": "KeyError",
"args": [
[
"bd72e6bd4eb474ca19ab213aa425117c40f29141d0abeccd77eca9c2ae7c54ae",
0
]
],
"message": "('bd72e6bd4eb474ca19ab213aa425117c40f29141d0abeccd77eca9c2ae7c54ae', 0)"
}
},
"id": 0,
"jsonrpc": "2.0"
} -
yes a lot
-
you sending requests to coindaddy?
-
Joined. -
Joined. -
-
Looks like coindaddy public server had some issues today... i'd advise using api.counterparty.io instead of the public coindaddy server... it'll be phased out eventually
- 20 June 2023 (15 messages)
-
I´ve publish this article for using the DEX, specially using BTC. I´ve added some warnings about the fact that the wallet needs to be open to complete the order when using BTC. Let me know if you find anything incorrect and I´ll change it. Did my best effort with the docs and feedbacks I got. https://medium.com/@rarestamp/counterparty-dex-tutorial-trading-tokens-and-using-btcpay-d539cfed68c
-
could we please leave a CORS enabled service.
public.coindaddy is front-end JS friendly endpoint, whereas api.counterparty is CORS blocking - so if public is going to go away can we please open CORS on api.counterparty? -
This please
-
Or atleast open CORS for selected origins
-
I had to switch to python because of CORS (which is probably better) but would be good to have to flexibility
-
Under prerequisites, 2 says you need an account, which is not true. That would immediately turn me away, and I’d stop reading then.
I feel like the warning doesn’t need to be such a warning with ⚠️⚠️ As you state, the wallet can remain locked. Keeping it bold like you have it is enough to emphasize the point.
I’d further suggest making the 2 transactions necessary for BTC DEx orders clear and upfront, since that necessitates keeping the wallet open. However, that’s just for buying tokens with BTC. Tokens can be listed to sell for BTC on the DEx, and the seller doesn’t need to worry about keeping their wallet open for a 2nd transaction. -
Sec. 1.d. - pair is misspelt as par
-
I too saw the bit about an account n i think they mean generate a key pair
-
Thank you both for reading It! Will change today those points. 💚
-
If you have an issue please document t it it a GitHub issue…. Need to be able to reproduce the issue your having…. Cuz I use the apis fine with CORS on xchain and api.counterparty.io via freewallet…. so dunno what issue you having n no time to dig…. If you want a fix or update, please document it all n I’ll look into it…. Way too busy to spend my time debugging in the dark…. Reproducible test cases pls👍🏻
-
Good morning👋😀
-
-
GM
-
Ok will make a codepen that demos it later to tag into an issue - thanks.
-
Perfect! Thank you❤️
- 21 June 2023 (30 messages)
-
Hello I tried to write in CP forum but need approval 😄
-
But basically I think that solution 1 proposed here https://forums.counterparty.io/t/solutions-to-rugspenser-problem/6623/3 by @jp_janssen could reduce a lot the scams and reactivate trades for art Stamps.Solutions to "rugspenser" problem
Attack vector: Scammer detects incoming buy and immediately sends another buy transaction with a higher fee. The scammer’s tx gets priority and the legit buyer loses his bitcoins. Possible solutions: 1. Pre-payment before full payment This requires a protocol change. The logic is simple. If less than a full dispense is detected, allow up to 12 blocks for the second tx. Perfectly safe as the protocol keeps the token on escrow. The buyer, if not trusting the seller, can thus make a tiny pre-pa...
-
its just a recreation of btcpay
-
if you’re going to do two payments then why not do a btcpay tx, match the order, then pay btc within 20 blocks?
-
also I mentioned at the end "I’m glad I pondered this but the ultimate flaw is still that the “scammer” could just “buy back” the token with a huge fee with unconfirmed tx’s still in queue. So it might not work"
-
very true
-
I like the concept that you can open a dispenser on an address you don’t control so that could be a “trusted” party. No one would have an issue buying from a Joe Looney sanctioned dispenser. You would get a refund for an over-buy and the trusted party could even take a cut for offering this service. The missing component is really at the UI layer to make this feasible and, in my mind, it solves the nastiest problems (though you could still get front-run by other buyers — but not lose your money in the process)
-
No protocol changes necessary either
Official Counterparty Dev Chat
Public archive of Telegram messages.
- 01 Jun 2023 (510)
- 02 Jun 2023 (124)
- 03 Jun 2023 (8)
- 04 Jun 2023 (30)
- 05 Jun 2023 (95)
- 06 Jun 2023 (133)
- 07 Jun 2023 (3)
- 08 Jun 2023 (1)
- 09 Jun 2023 (6)
- 11 Jun 2023 (33)
- 13 Jun 2023 (1)
- 15 Jun 2023 (14)
- 16 Jun 2023 (3)
- 19 Jun 2023 (13)
- 20 Jun 2023 (15)
- 21 Jun 2023 (30)
- 22 Jun 2023 (50)
- 23 Jun 2023 (3)
- 25 Jun 2023 (6)
- 26 Jun 2023 (1)
- 29 Jun 2023 (2)