- 01 September 2023 (7 messages)
-
https://jdogresorg.github.io/BTNS-Decoder/
Code: https://github.com/jdogresorg/BTNS-Decoder/
FYI... Here is a little library/tool I threw together which handles taking a tx_hash, a tx_hex, or a raw BTNS command, and decodes it into the various parts.
This tool / library is still in development, and is meant for BTNS, but can be used by Counterparty users to decode Counterparty transaction data directly from a raw bitcoin transaction.
Thanks goes out to @jp_janssen for writing his Electrum-Counterparty tools, which helped me greatly in building this library.
TLDR... javascript code to decode BTC/XCP/BTNS transaction dataGitHub - jdogresorg/BTNS-Decoder: Broadcast Token Naming System (BTNS) Transaction DecoderBroadcast Token Naming System (BTNS) Transaction Decoder - jdogresorg/BTNS-Decoder
-
very nice, having the ability to decode a txhex and for it not to be needing to be in a block is ace -
yup.. that was the whole point of the library... to be able to decode a raw/unsigned transaction BEFORE signing... and decode WTF it is doing and alert the people to make an informed decision BEFORE they sign..... right now too much trust in signing a black hole tx... this library aims to fix that 🙂
- 03 September 2023 (1 messages)
- 04 September 2023 (1 messages)
- 05 September 2023 (2 messages)
-
just made a pull request for this, along with a few others on the Documentation side of the github as well ❤️
https://github.com/CounterpartyXCP/cips/pull/108Updating information on CIP1 by davestaxcp · Pull Request #108 · CounterpartyXCP/cipsA few spots of CIP1 pointed towards the now offline (old) Counterparty Forums. I changed the links to the new forum links that denote the correct area the CIP1 wanted to point new developers and us...
- 07 September 2023 (7 messages)
-
-
"balances"... BTC balances? CP asset balances? How does this differ from addrindexrs which keeps track of utxos and balances? https://github.com/counterpartyXCP/addrindexrsGitHub - CounterpartyXCP/addrindexrs: An efficient index of bitcoin addresses based on electrs. Fork of addrindexrs of Samourai Wallet
An efficient index of bitcoin addresses based on electrs. Fork of addrindexrs of Samourai Wallet - GitHub - CounterpartyXCP/addrindexrs: An efficient index of bitcoin addresses based on electrs. Fo...
-
CIP31 - Enhanced File Encoding Support · CounterpartyXCP/cips · Discussion #109
Counterparty currently has an issue where file data is being stored in the counterparty database, and we are unable to move forward with updates (like P2WSH) which would allow much larger transacti...
-
Set max dispense limit on dispensers · CounterpartyXCP/cips · Discussion #112
Currently anyone is able to create dispensers and sell tokens with no limitation on how many dispenses a single dispenser can have. This has led to the creation of dispensers which will stay open a...
- 08 September 2023 (9 messages)
-
Good work! Shall i add this to the CIP directory?
Is the draft ready? -
a draft and PR is ready.... you can add it to the CIP repo if you would like (your the CIP editor, so your call what gets added and what doesn't 👍️️ ) ... https://github.com/CounterpartyXCP/cips/pull/111 ... unless there are some major objections to this approach, I plan to get this included in the next release.... IMO the next release shoudl be a "maintenance release" where we fix various things that are broken in preparation for the NEXT release which will include P2WSH data encoding and support for taproot addresses, etc.Enhanced File Encoding Support by jdogresorg · Pull Request #111 · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
FYI... also moving forward with 2 other updates which are changes, but which I believe do not require a full CIP.... redefining "EMPTY" to mean no BTC or XCP balance history.... and adding the origin field to dispensers, to allow refill/closing of dispensers from the origin address.
-
Redefine `EMPTY` address to mean no XCP or BTC history · Issue #1251 · CounterpartyXCP/counterparty-lib
Currently an EMPTY address is defined as any address which does not have any Counterparty (CP) history associated with it. This definition has led to users being able to open up dispensers on excha...
-
Add `origin` address field to dispensers · Issue #1250 · CounterpartyXCP/counterparty-lib
Joe has come up with a very elegant way to allow refilling and closing of dispensers opened on empty addresses by adding an origin field to the dispensers table. We should make this update and get ...
-
Also would like to get the MAX_DISPENSES change included in the next release..... another one I dont think needs a CIP.... tho would like to wait another week or two for additional feedback before making this into an "issue" and getting it in the next release... https://github.com/CounterpartyXCP/cips/discussions/112Set max dispense limit on dispensers · CounterpartyXCP/cips · Discussion #112
Currently anyone is able to create dispensers and sell tokens with no limitation on how many dispenses a single dispenser can have. This has led to the creation of dispensers which will stay open a...
-
</end next release braindump>
- 11 September 2023 (24 messages)
-
Who are these bots talking to?
-
-
Of course Counterparty dev chat ends up with the retarded AI
-
Agree. It solves an issue where dispensers don't work as intended. No cip needed, github discussion sufficient imo.
-
I will add the cip asap, prolly tommorow
-
1000 dispense limit is overkill, and an arbitrarily small number.
A very likely problem arises when anyone prints a dispenser address with intention of advertising sales. -
It seems a shame going forward to limit total dispenses due the fact 'empty address' was not initially defined as no btc history and no cp history but just as no counterparty history
I think it would be the right thing to do to redefine it as both no btc and no cp history and allowing dispensers to be closed using the source as the origin which would allow for these problematic dispensers that exist to be closed if the creator wishes to do so
Perhaps set a fee e.g. 0.00000001 xcp per dispense .. xcp escrowed when creating dispenser ... and xcp is returned if its unused and dispenser is closed just as the tokens that are to be dispensed are -
rather than limit things charge xcp for database storage costs
-
have a free tier but also a paid one, perhaps <=500 dispenses it's free but if >500 then xcp is needed also
-
Isn’t this file encoding technique just more of a load on the CP node operators since it will be an additional lookup on bitcoin core via the api? Rather than solving the underlying cp database issues?
Was 1024 chars chosen based on empirical data in the db currently? Much like the stats on the dispenser changes -
The 1024 limitation would only be imposed going forward (past stamps would stay in DB, so backwards compatible). The API calls would act as it does now and return what is in the database, UNLESS the API passes the raw_data flag, at which point THEN the transaction data will be looked up using the raw transaction (bitcoind) instead of the CP database… so, this really only limits what goes into the database going forward and keeps database queries fast.
-
Nbd on our end since it’s all pushed into a secondary database outside of CP such as with xchain. Just concerned it doesn’t help with the underlying db problems and creates some complexity.
Curious how nodes that don’t upgrade to this immediately would handle things.. just continue to store the longer ones in the database or create a divergence on valid/invalid issuances? -
I don’t see anything at the cip level regarding valid/invalid so I guess it’s just a refresh of the cp db at the time of upgrade brings everything in line. Not a bad solution to move forward imho. Not quite sure where/how the mimetype comes into play if that’s defined on the issuance or detected (edit: I see how the data type field would come into play now) but what happens if that mime type is incorrect or missing ? Are we relying to much on user provided data?
-
Kind of why we rely on file decoding to determine the suffix in stamps rather than requiring extra on chain data to determine
-
A user can certainly try to auto-detect content type based on file data, but I feel it is important for a user to be able to specify the specific mime-type of the file data, which overrides any auto-detected mime-type….. This also allows for throwing custom mime-types which would not be auto-detected… and makes CP ordinals-style encoding pretty straightforward 👍
-
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 0
OP_PUSH "Hello, world!"
OP_ENDIF -
Cool. Just seems like quite a heavy cost of adding that data on chain but likely worth it
-
Is there a proposed default mimetype?
-
Plain/text
-
Pulling out non consensus data is a good start to cleaning up the Counterparty db
-
Nodes that don’t upgrade wouldn’t recognize any txs that use the op_false data wrapper
-
Taproot upgrade is a consensus change (hard fork)
- 12 September 2023 (30 messages)
-
Would the dispenser limit apply to new dispensers only or historical ones as well? For instance, this one by John Villarz was opened over 4 years ago. Might need to load-up…
https://xchain.io/tx/013fcaacae02f4f60abf66f60692b8df27aaa1f78072d0a9f2291df502d58b57 -
Thanks everyone for chiming in. I encourage also posting under the github discussions.
-
if Counterparty is hard forking for taproot upgrade then why not then hard fork out the problematic dispenses?
-
Good to see the creator of dispensers didn't think twenty five thousand dispenses was a problem.
if I want to dispense a million tokens should I open the dispenser quick before new rules are enforced? -
-
John n I came up with the idea of dispensers, primarily to make using btc on xcp easier (one single tx instead of many like on the DEX)
A 1000 dispense limit is just a new limitation to prevent abusive dispensers opened up on high-volume addresses.
One can “refill” a dispenser from origin address to reset the 1000 counter…. Or open a new dispenser. -
A refill every 1000 tokens imposes a BTC tax on a successfull genuine dispenser, and I can see how that works as an antispam mechanism but could it not also be addressed using XCP ? allowing persons who wish to open longlife dispensers pay an XCP fee like is done for an asset registration or a sweep or even based on amounts like dividends? the more dispenses you require the more xcp you pay ... or is the low price of XCP an issue as its still too cheap to spam the database?
I am just voicing my ideas arounc this issue, I have not yet posted to the github as I not sure its an economically feasible option to use XCP to prevent this type of abusive dispenser exploit? as I appreciate large dispensers opened on busy addresses can generate lots of database entries.
BTC tx fee pressure it seems is now a constant thing whereas in the past it was not, i am not saying the mempool will never clear but that is a possibility so previosly it would have been cheap to refill a dispenser, but we must now expect the cost to refill a dispenser to keep rising as btc tx fees rise -
I do like the idea of having the option to make "longlife dispensers" using XCP for a fee
-
since Jdog mentioned only 4 dispensers have gone farther than 1000, it is an interesting addition which stills gives freedom of the dispenser creator
-
... but would not necessarily solve the "limitation to prevent abusive dispensers opened up on high-volume addresses"
-
a divisible asset with a 100 billion quantity dispensed at a rate of 0.00000001 is a possibility so something needs doing
-
but what if the dispenser is set up on an address that someone knows will have a high volume of btc tx's coming in beforehand - which in turn will create enormous "bloat on the counterparty database"
-
and theoretically in that circumstance right, if you bought a million of those assets at a rare of 0.0000001 it would not count as 1 million dispenses, but only 1 dispense
-
dispenser is per btc tx count not per "written" dispense
-
as per jdogs response in the github
-
-
yeah every 1000 dispenses no matter how many or how few actual tokens dispensed
-
Another topic though is how this relates to dispenser creation from the Source address vs not the source address and what you mentioned relating to "redefining it as both no btc and no cp history and allowing dispensers to be closed using the source as the origin" is interesting too in my opinion
-
and relates in the situation of dispensers being opened up on a somewhat "foreign" address that isn't necessarily connect to counterparty for its purpose (ex. public exchange fund addresses)
-
being able to open dispensers on known busy foreign addresses is an issue .. turning an exchange into a token spamming machine can be laughed at but causes database bloat .. if not a unused empty addres then perhaps a signed message is needed to prove ownership of the address to be used as a dispenser
-
the signed message sounds like a solution to this imo
-
would love to see you post all of your thoughts in the github discussion, as not everyone in the community necessarily reads everything here
-
yeah you are right .. I need to do the math and work out how many dispenses could be triggered by a 100 billion quantity divisible asset that's dispensed at a rate of 0.00000001 for every 10,000 satoshis .. I am imagining its a lot
-
Exactly this
-
My idea was to just have them expire like dex orders, jdogs 1000 limit is a better compromise imo
-
The option to have dex orders not expire has also been proposed unofficially on several occasions.
I admire the refill option but also wonder if this solution is a match for the problem.
No xcp history was enforced and no btc history was implied. Therefore this much of a change is warranted as it is due to an oversight IMHO -
"The option to have dex orders not expire has also been proposed unofficially on several occasions" - This would be really nice imo too and often wondered the possible problems if this was the case
-
sounds like this discussion possibly has already taken place somewhere
-
looks like it is referenced here but wonder if there is more information on the Dex Order Expiration reasoning somewhere else too?
https://forums.counterparty.io/t/dex-orders-expiration-limit/603DEX orders expiration limitWhat is the reason for 7 day expiration period? Setting up orders cost money. I think this limit could significantly reduce liquidity on DEX for high quality assets.Counterparty now suffers from almost zero trade volumes. Unlimited orders could solve some part of the problem.
- 13 September 2023 (3 messages)
-
Increase max order expiration
A number of users in the community have expressed frustrations with the current max order expiration of 8064 blocks (2 months). The purpose of this post is to discuss interest in increasing the max order expiration and if so, what should the max allowed be? 1.) Could increasing the max_expiration have any negative effects on the CP system (more orders to check for matches each block, etc)? 2.) What should the max_expiration be increased to? (48,384 blocks = 1 year) Thoughts?
-
thank you!
-
Joined. - 14 September 2023 (20 messages)
-
So…. Require use of xcp (a “shitcoin”) which is one of the major complaints about using Counterparty?
I appreciate the feedback, but imo, if anything, CP should go out of its way to keep things pure BTC wherever possible n not require the use of XCP any more than we already do.
I disagree that this is a change which will cause problems…. We’ve been running dispensers for 4+ years n only 3 have gone over the “over 1000 dispenses” limit… and all 3 are the “abusive” dispensers opened on exchange hot-wallet addresses.
Imo this is a non-issue, the 1000 limit can easily be “reset” via a refill…. Seems like a much simpler approach that addresses the dispenser “abuse” issue now.
We can certainly discuss an optional XCP fee on certain actions within CP (huge dispensers, never-expiring DEX orders, etc.) , but I don’t feel an XCP fee on dispensers is appropriate at this time. -
Definitely putting all my savings in that!! Looks legit 😅
-
Spam removed… n you now have admin powers to delete spam messages 👍🏻
-
You won't be able to refill on those hot wallet addresses, right?
-
You can refill the dispenser from origin (address that first opened the dispenser) to reset the 1000 counter…. You can also close a dispenser from origin, in which case the escrowed tokens in the dispenser are credited back to the origin address.
The origin field update allows for creating/refilling/closing a dispenser on an “empty” address…. Should make using/managing dispensers much easier/cheaper than having to manually transfer dispenser balances back between addresses -
Being able to remotely close a dispenser with no sales will help prevent people from fulfilling their own dispensers and in effect wash trading because it's easier to close that way, as they say
-
When you refill, the no-btc-history rule won't kick in?
-
the no-btc-history rule is only in effect when opening a new dispenser on an EMPTY address.... this new origin field just tweaks the refill/close logic to allow a refill/close from origin as well as source
-
Brings up an interesting question tho.... should we perhaps allow origin to open up additional dispensers on that address even tho it is not technically "EMPTY"?..... Currently origin is only able to open one dispenser on an "EMPTY" address... With this tweak, we could allow for an origin address to open up multiple dispensers on an "EMPTY" address.....could also allow for origin to continue open up/refill/close dispensers on that address
-
once an origin address opens up a dispenser on an EMPTY address... that origin address can then open/refill/close/manage many dispensers on that "EMPTY" address, even tho it is no longer empty..... first origin to use an "EMPTY" address gains the rights to manage dispensers (opened by `origin`) on that address in the future 🙂
- 15 September 2023 (9 messages)
-
Question: the oxbt spam would still be able to continue, except, for the fact, it would cost the dispenser owner a TX fee per 1k dispenses, is that correct? -
The refill ability would allow the ability for this to continue on an address they do not hold the key for? The only deterrent is the tx fee per 1k dispenses.
-
I don’t have an opinion either way, because there is no perfect solution, no matter what is implemented, it is give and take.
-
i believe it would close when update activates and would only be able to be refilled from the dispenser address itself
-
the origin update handles setting the origin field in the dispensers table retroactively.... so, if you opened a dispenser on an EMPTY address in the past, and it has not closed yet, you should be able to do a refill on it... Javier has the PR for origin ready.... now working on the PR for redefining EMPTY to mean no BTC or XCP history 🙂
-
Added origin field to dispensers, it's the creator of the dispenser by pataegrillo · Pull Request #1253 · CounterpartyXCP/counterparty-lib
Now the dispenser origin address can close and refill the dispenser
-
So will dispensers opened on active btc addresses pre-update (like exchange addresses) be able to be refilled?
-
yup... they will.. tho the 3 problem address dispensers were opened by @leixiaobo .... and once he has the ability to close those dispensers after the origin field update.... I believe he will close them.
-
Gotcha
- 16 September 2023 (3 messages)
-
None
-
Maybe just me but I associate official with being centralized. 🤔
-
Sorry you feel that way JP… it’s just a word…. I know you know some of the history behind why the word "official" is used in the one CP channel on telegram... Multiple cp rooms exist… including one held hostage by a former CP foundation member which is used to talk negatively about Counterparty, tell people the platform is dead, etc... that is why “official” was used, so the names were different.
I've explained the reasoning behind the use of the word a few times in multiple channels, but still... IMO haters gonna hate.
Yes, seriously... we have whole github threads about how we should not use the word "official"... LOL.. WTF?
https://github.com/CounterpartyXCP/cips/discussions/97
Personally I think it is a waste of time to squabble over silly things like the use of a single word.
The more time wasted attacking devs for running sites and services, using specific words, and pushing forward ideas, the less time is spent on actual development and moving CP forward.Remove the word "official" from social media · CounterpartyXCP/cips · Discussion #97Lets promote decentralization by not claiming to be the "official" source of data for anything other than the PROTOCOL repository. Looking specifically at: t.me/CounterpartyXCP But then t...
- 25 September 2023 (1 messages)
-
I'd like to point out this Pull Request in the Counterparty Documentation as very important to be looked over as soon as possible for the safety of new users... Because of the outdated information there are scammers posing as support in the Counterparty Forums
https://github.com/CounterpartyXCP/Documentation/pull/167Updating "Getting Support on the Forums" by davestaxcp · Pull Request #167 · CounterpartyXCP/DocumentationOld documentation had no current link to the Counterparty Forums and said "Support" area was for Private Support when it is in fact public. Also updated the screenshots to the new UI of t...
- 30 September 2023 (1 messages)
