- 19 May 2023 (156 messages)
-
Do you expect to be the only minter or transferrer of src-20 tokens? -
Drive xcp usage and use fund to pay for scaling -
No were just trying yo be correct. I should imagine very soon this will be over for us. It was,only supposed to be an,art project not an eth killer
-
But of course we are about cooperation
-
But this is why that arrangement can’t work
-
Either way it's fine
-
But it looks better for us all that we are clear. I'm nit trying at least tio attack xcp
-
You see why though right?
-
Yes
-
Cause someone else will
-
That's why we did ironically
-
And I also support xcp numeric fee
-
But just to expalain.. we did come and offer money
-
And we did donate
-
So not that attacky imo
-
That's all
-
It’s an issue that gets exponentially worse since EVERY action is an asset issuance
-
Ideally a dynamic fee. If rate of new registration higher than some threshold, then add xcp fee. -
Are all src-20 transactions XCP transactions? I’ve read the githubs for the spec and api. Thanks for your time. I see both sides issues. -
What I worry there is that it’s not clear to users when that happens
-
I think we need to identify a starting block so it’s clear when the fee kicks in
-
What are we trying to prevent? Eli5
-
You do?
-
Reminds me of the good debates on bitcoin talk back in the day.
-
Asset issuance increasing exponentially to service a new overlay asset system that cannabilizes the existing system
-
How far in the future?
-
I had mentioned a week previously, I still think that’s reasonable
-
Jdog created an example of how a token layer like src-20 could work leveraging broadcasts so there’s a reference available to implement that way, i really don’t understand the logic as to why SRC-20 is so opposed to doing it that way
-
Is that sufficient for the people like Juan who do a full reparse? 🤔
-
Why would he do a full reparse if his node is already up to date?
-
I’d love to see or read a comparison of ordinals, stamps, traditional xcp assets and BTNS from the developers perspective. Size, storage location, features, details. Did Mike invent a nuke or something?
-
Trust issues.
-
Makes no sense, it would activate at X block
-
I think his node is nonstandard. Dont quote me there.
-
Check dm ser
-
He did refuse to update for a while but xcp.dev does use the latest node now.
What Juan did was do a full parse without bootstrap. He discovered some bugs that were since fixed. He deserves big credit for that. -
I remember those days.
-
Agree! Def glad he did that
-
But my question is why would he need to do another full reparse
-
I’m confused here. If SRC supports paying an XCP fee, what is the issue? -
Yes ofc. Wagmi
-
Raíces money for instrastructure
-
Fix multi send etc
-
I guess you're right. No need
-
Ngl it seems at odds with your guys decision not to move src-20 to broadcasts
-
I'm clear we offered. And long term we would work towards it. Ifeel like like that was not left up to us and we were efficiency told to chiste what jdog had written fir us an accept his narrative.
-
That's where we differ. Nit about not playing our fair share and or helping
-
I also think its OK to make hay while the sunshines
-
Well I’m not jdog, and jdog has stated he doesn’t plan to do anything unilaterally, so why not have the conversation here without jdog in the mix
-
It is what it is. I'm just trying to explaon how I feel about it
-
Lol nothing has happened
-
How is it “is what it is”
-
We’re having a discussion about how to move forward
-
I mean we are where we are.. not in a bad way. We can start from now
-
Yea don't take my tone wrong. I'm down to help
-
Then why not move to broadcasts which started this whole mess?
-
That would be the best thing possible
-
Right now I think we are clear eoth our intención and we speak,as a group. But I'm quite sure we prefer cooperación. That suits us all
-
I think that’s great! But can you answer why you don’t want to move to broadcasts?
-
I think that the efficiency question is more relevant. We are paying for space and we have a commercial model that works for us
-
Because it affects our revenue model speaking personally
-
It doesn’t tho
-
You can do the same exact thing with broadcasts and charge to mint
-
If it doesn't let's proceed as a team to do that
-
I'm quite sure we said we would
-
You just said the opposite tho
-
But we had 1 week. Which tuercen into 4 hours
-
Nothing has happened
-
It’s now 10 days plus from when this convo started
-
So we can’t stop you if you pay the fee… so why mention forking
-
I'm also confused
-
Hahaha
-
Man
-
We are ALL confused
-
Breakdown in communication I'm sure we can solve
-
The fee is meant to stop src but if you guys are willing to pay the fee, their is nothing we can do to stop you so this is a non issue
-
Exactly
-
So why are we arguing
-
It's just a question of ethics and memes
-
From my perspective, and don’t take this the wrong way, it appears you guys just don’t feel like doing anything different
-
And it seems like you guys want to pay the fee
-
Doing anything different? We did stamps.. now this.. the first different thing in ages.. and we are just a few ppl
-
We are trying
-
And we are doing
-
I’m talking about switching from issuances to broadcasts
-
As far as things are I'm ok with u forking
-
But ID just rather be friends
-
It’s an easy fix, nothing changes from user perspective and you can still charge for minting
-
It’s win-win but you guys don’t want to for “reasons”?
-
Are broadcasts as immutable?
-
Yes they’re onchain like everything else
-
We got threatened
-
And we close nit to he
-
Lets nit go round that again
-
So your pride is preventing you?
-
No
-
I'm the one here
-
Nothing is preventing anythin
-
I’m just trying to figure out the reason you don’t want to
-
We will decide ad a,group how to procede. But we welcome ur colaboración on the technicals
-
What does that mean
-
It's not up to me alome
-
That's,what it means
-
Ok so you will talk to others and report back here?
-
Sounds reasonable
-
We are actually a little busy lol. But I will speak to the guys later this evening and get back to you
-
No problem, I appreciate it
-
I can certainly help with technical implementation if you guys want
-
I want peace, prosperity and fun, and because I have minted KAREN I also want to speak to the manager -
I think if we can implement a numeric fee and move src-20 to broadcasts (where they wouldn’t be affected by fee) it’s a win for every one
-
There are a couple of question I have techincally But I will dm you shortly if that's ok.
-
Yep np, I’m gonna be unavailable shortly for the next few hours but pls send and I’ll answer when I have a chance
-
Based
-
This convo has made me realize over the last few days that Counterparty is actually the more responsible token creator on Bitcoin because XCP is a spam prevention tool for Bitcoin
-
To be biased against XCP while being biased against Bitcoin spam makes no sense. Even more so when you consider XCP was literally created from Bitcoin.
-
Basically any use case besides Bitcoin as money is unacceptable, even if the token was created from Bitcoin to prevent spam.
-
Been trying to catch up with conversation, I'm out of the loop on some of this but it sounds like the main question at the moment is what concerns or reasons are there moving src-20 to Broadcasts. This seems that as MA said could be a win - win. -
Every src-20 action (mint/deploy/transfer) issues a numeric locked asset with no supply… no meaningful way to use CP…. 10% of xcp assets ever created were created in the last week as unusable assets… discussions have been had at length.
Decision has been made, fork on Monday with xcp fee on numerics… will activate Friday… clear explanation of what issue is. -
None
-
Well put, this I understand. Can you provide an example TX showing the created unused asset, for science?
-
Pick any of the 3000+ pending src-20 txs…. Here is one… https://xchain.io/tx/2373547
-
Dunno if it’s an deploy or mint or transfer…. But in all cases, spams a locked unusable asset… can decode json to see for yourself
-
{"p": "src-20", "op": "mint", "tick": "NEXUS", "amt": "69696"} - 20 May 2023 (73 messages)
-
Joined. -
I suggest a fee of 0.01 XCP on every asset issuance, initial as well as updates.
I believe this solves spam better. A 0.25 XCP fee on initial issuance will kill legitimate use cases, like 1/1 collections.
Full reasoning in the forum: https://forums.counterparty.io/t/fee-on-numeric-assets/6601Fee 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...
-
If the goal is to stop “spam”, it needs to be cost prohibitive to prevent spam.
Even @ $100 XCP, that’s still only $1. Right now, 4.5 cents.
If someone is minting a 10,000 collection, they will pay $50-100k in Bitcoin fees and only $425 in XCP. 0.5-1% of the BTC fees required.
1% is not a high enough threshold to make a difference in spam prevention. -
At 0.01, I would vote to leave it free tbh.
-
Maybe 0.25 -
Or leave it at 0.5 and make XCP valuable kek
-
@jdogresorg is there a separate xchain chat?
-
I don’t think the additional xcp fee will do anything to discourage the src-20 guys to change to a less abusive method…. They have had plenty of time to switch if they wanted to “cooperate”… so, I expect the spamming to continue after the xcp fee is active. The fork is just the protocols way of closing an attack vector and putting all assets on level playing field.
The core issue is spamming numeric unusable assets and not using cp in any meaningful way.
IMO this behavior will continue until the public is made aware there is an issue…
First will deal with fork on Monday…. Once that is out the door I (personally) will begin dealing with raising awareness of the SRC-20 issue…. Their community is in the dark that there is even an issue…. That will change this week.
Community decided path forward for protocol👍🏻
I decide path forward for my own products n tools…. N will be using them to raise awareness.👍🏻 -
Nope. No chat, it’s a personal project, not community one…
-
Not short term, but eventually it will.
I commend the src and stamps devs willingness and support of the fee. -
I am not gonna discuss src-20 here anymore.. burned out on it… and no more energy to correct false narratives (cooperation and funding…. Neither have happened, all just lip service)
Done talking. Time for action. 👍🏻 -
Is this what is being referred to as ‘spam’? Genuine question. Sounds like code executing as designed to me. Thanks for your efforts. I bet it’s a lot right now.
-
You might benefit from creating a chat for xchain & coindaddy and directing conversations that are not protocol specific there, to help you with your hat juggling addiction.
-
Transfers are not going on assets by the way. Those were never implemented in the current system. Just a few for test.
Making progress - there are just a few big limitations with using broadcast which we are seeing if we can work around and get creative with. We aren’t just sticking with assets just for the hell of it. They are required. Maybe a 1:1 for src tied to a broadcast but it seems silly making two transactions as well. -
It’s spam to CP in my opinion.
It doesn’t utilize CP infrastructure in anyway besides piggy backing off of the asset table.
If continued forever, it will degrade the use for everyone who uses CP in a substantial way. -
we are still utilizing features of CP and issuances for src-20 btw. In a switch to broadcast methods we lose the ability to mint/issue them directly to emblem vaults for example. These are part of the limitations imposed we need to consider and work around.
-
that ability is a feature of CP we rely upon at the moment. All of this rush to make something happen without time to sus out all the implications isn't helping anyone. we do understand the supposed db limitation issues, but that is a core problem of CP that has needed to be addressed for many years through a database redesign. There is no reason such a small database should be this inefficient.
-
Can you provide a Tx for science of one of these spam transactions?
-
ed218bae5dde55becf7ee8e7792c30ee756578c2b5daae85f4e7063c5a7df203
-
Stampchain does take a while to load
-
When sifting through pages
-
On my computer
-
I press the button and need to wait like 30 seconds lol
-
That doesn’t happen on xchain
-
You and everyone are making valid points. But also realize that Rushing Begets Rushing. You rushed to release something that is now controversial and arguably detrimental. Now there is a rush to address it. If everyone was less opportunistic and approached new sudden CP use case ideas…. all in response to Ordinals, then CP would look responsible as it has been for years. Now CP is approaching Clusterfuck mode. Congrats 🙃
And yet, I’m with you that everyone should calm down and chill… make some smart moves and not take anything personal. -
it's loading 1000 images per page. we reduce that down to 50 and it will be snappy
-
🤑
-
Status:valid
-
Is the zero quantity intentional by the issuer or a side effect of the protocol? Hard to tell.
-
intentional for now to prevent assets moving on the "sub"-layer but is up for consideration.. assets on top of assets on top of assets really
-
I dont follow
-
Is this your tx?
-
That’s an src-20 transaction
-
Xchain, xchain, xchain. What about other fednode users? Changing the protocol just for xchain? These problems need a response not a reaction.
-
is there a list of these other fednodes?
-
Sending 10,000,000 spam emails is also valid on the network.
-
You can mint and issue in a single broadcast by concatenating the commands
-
You can literally do whatever you want with your protocol, you make the rules
-
There is no reason at all to use assets as a store for arbitrary data
-
A protocol update is a fednode update
-
The reason this is so frustrating is because it’s like you’re shitting in the sink because you can’t figure out how the toilet works
-
And jdog is saying, hey you need to start paying to use the bathroom if youre gonna keep shitting in the sink
-
The reason mostly is as mentioned. Broadcasts limit us from sending them to an emblem vault for example.
-
Emblem vault would just need an api to your indexer
-
Yes but you mentioned you “can’t” and I just explained how you “can”
-
That’s good feedback! As mentioned we do hope to launch the transfers on broadcast here shortly so we can start making a transition for the others
-
Sometimes I have the problem of assuming everyone understands things the way I do, so I apologize for assuming
-
As of now we kept transfers disabled to minimize impact while allowing issuance and mints
-
To me it’s clear as day how to leverage broadcasts to do everything you want to do
-
I’m down to help, just got back from morning kids soccer games so I’ve got availability
-
The other limitation with broadcast is that we cannot issue (owner and issuer) to a third party on their behalf. That is not a deal breaker. We just need a wallet to support users being able to easily create and broadcast with the required formats.
-
You just need a new command
-
Issue;changeowner
-
Is transfer the equivalent of send?
-
In Counterparty send is send and transfer is ownership change
-
Stop the shitting in the sink, dont charge admission. It doesn’t matter how much shit is in your sandwich; if there’s shit in it, it’s a shit sandwich.
-
Hahaha I would prefer the sink shitting to stop as well
-
SMTP didn’t change to stop spam. DKIM, SPF and DMARC (other protocols) came about to solve those problems.
-
SMTP is bitcoin in this analogy
-
SMTP is XCP in my analogy.
-
There could be a dev chat somewhere with BTC core devs planning on booting counterparty right now for all we know.
-
Yes.
-
Sure it wouldn’t be the first time
-
Got it
-
XCPs function within Counterparty is anti-spam
-
-
Comparing hydren-crypto:main...loon3:patch-1 · hydren-crypto/stampchain
proof of concept for displaying stamp images. Contribute to hydren-crypto/stampchain development by creating an account on GitHub.
-
just heads up, docs seems unaccesible on the CP site. -
https://docs.counterparty.io/ this one worksCounterparty | CounterpartyDocumentation for Counterparty protocol on Bitcoin
-
i think its the links in the github repo that are dead
-
perfect thanks guys
-
Someone please implement a HTTP 301 redirect on the server answering these dead doc links please. These links have been a pita for a long time. Definitely a top 10 FAQ.
-
- 21 May 2023 (41 messages)
-
The latest MINOR release seems to have broken consensus. This is unexpected.
Same up until:
- https://xcp.dev/block/790338
- https://xchain.io/block/790338
Different from the next block:
- https://xcp.dev/block/790339
- https://xchain.io/block/790339 -
I located the tx and raised an issue on github .. https://github.com/CounterpartyXCP/counterparty-lib/issues/1240Tx included in v9.60.1 but not in v9.60.2 · Issue #1240 · CounterpartyXCP/counterparty-lib
This dispense is shown on xcp.dev - https://www.xcp.dev/tx/16bd438b1dee6b1f750758eeabef7a876c204082a088c48ca51c416d6651d5db It is not a Counterparty tx according to xchain - https://xchain.io/tx/16...
-
Joined. -
https://xchain.io/tx/fb057107cff648877e8233b82f8a1791d763dd2cba321281e8d302e8a59e6290 not loading on xcp.dev
-
My github is for work, feel free to post this tx there if that helps.
-
Bcs xcp.dev is on 9.60.1 and on this version the dispenser was emptied two blocks earlier
-
🧐
-
Strange doesn’t seem to be anything out of the ordinary with that Tx
-
Definitely block 790339 https://mempool.space/tx/16bd438b1dee6b1f750758eeabef7a876c204082a088c48ca51c416d6651d5dbBitcoin Transaction: 16bd438b1dee6b1f750758eeabef7a876c204082a088c48ca51c416d6651d5db
Explore the full Bitcoin ecosystem with mempool.space
-
Locked at 790339 replaced with higher fee. https://blockstream.info/tx/fb057107cff648877e8233b82f8a1791d763dd2cba321281e8d302e8a59e6290Blockstream Block Explorer
Blockstream Explorer is an open source block explorer providing detailed blockchain data across Bitcoin, Testnet, and Liquid. Supports Tor and tracking-free.
-
I wonder if this is just an xchain issue and not 9.60.2 issue
-
I don’t see anything in that update that would affect dispenser parsing
-
Have you tried querying public development server directly?
-
Looks like .dev is using lock and xchain is using higher fee tx.
-
Then the question is, is this due to timing, programming or displaying.
-
Confirmed, no tx appears in 9.60.2 database for the above tx
root@sites:/home/jdog# sqlite3 federatednode/data/counterparty/counterparty.db
SQLite version 3.37.2 2022-01-06 13:25:41
Enter ".help" for usage hints.
sqlite> select * from dispenses where tx_hash='16bd438b1dee6b1f750758eeabef7a876c204082a088c48ca51c416d6651d5db';
sqlite>
Will dig into this issue on Monday (flying today) and once issue is resolved, will put out fix and numeric xcp fee. -
@jp_janssen Thanks for finding this issue and quickly creating a github issue with tech details so we can dig in and confirm.
-
Tnx. And credit to Juan for making me aware of inconsistent block hashes
-
Yes, having multiple block explorers is a GOOD thing, and leads to more consistent results and issues being found faster.
-
@jp_janssen have you identified any other issues besides this one dispense? Checking things here... doing reparse on 9.60.1 bootstrap database, then letting it catch up to be fully synced, then checking for missing tx.. reparse will take about 12 hours or more... so, pls LMK if you find any other issue txs, or if the issue is just limited to this one problem tx 👍️️️️️️
-
I had a lot of assets that ended up with different timestamps fyi
-
The only one i found but i looked manually so there could be more.
-
technical details are what is needed... not general statements. if you have specific issues, document them.
-
i didn't have a chance to go dig for details yet, just wanted to mention as something to look out for while everyone is comparing
-
busy debugging the insufficent btc error which has gotten more problematic in this release. will post findings and likely a fix when i find it
-
aka the usual fixes of consolidating or adding more utxo's don't appear to help the way it filters for them. will deffo post my findings on this
-
got ya. if you find anything, please document it.... at this point seems just like an issue with a bad bootstrap being copied out (cuz javier and I dont have a dedicated dev server... so we have to do dev on xchain servers and then copy databases back and forth and such).... yet another thing that CP dev could use... an actual decicated development server..... anyway, doing reparse of the 9.60.1 bootstrap database which is known good for many months... doing reparse on 9.60.2, then let it catch up and we will see whats what... I believe it is just an isolated issue with a single missing from the bootstrap database... but, will know more in 24 hours once reparse is done and database is fully synced
-
if you discover any more issues, please document in separate github issues and we will dig into it and put out a 9.60.3 release once the issue is identified and fixed.
-
https://jpja.github.io/Electrum-Counterparty/decode_tx.html api token expire? Is this newt tool yours? Looks helpful but I could not get it to work.
-
Works for most tx types ..as long as blockcypher api is up
-
Which tx did it not work for you?
-
The tx’s we were all just diagnosing in here for example. It may be client side. I’m majority on mobile lately. I’ll try on desktop and report back.
-
@pataegrillo @jdogresorg Here is a start to the Insufficient BTC error which happens on both sends and issuances. Definitely something with addrindexrs. Will help dig deeper when I can.
https://github.com/CounterpartyXCP/counterparty-lib/issues/1242 -
Thx for the details. Will dig in tomorrow
-
excellent, went down the rabbithole to addrindexrs, and also got a fix in there for the dict' object has no attribute 'split'" which I have seen pop up in freewallet as well.
-
Have also seen split quite a lot
-
it's not handling the dictionary correctly. this fixes, but doesn't seem related to the insufficient fee error
def unpack_outpoint(outpoint):
if isinstance(outpoint, dict):
txid = outpoint.get("tx_hash")
vout = outpoint.get("vout")
else: # if it's not a dict, assume it's a string
txid, vout = outpoint.split(':')
return (txid, int(vout)) -
Is there an easy way to check the port 4000/_api/ uri is responding without using credential’s that I’m missing? Was going to just use nginx to pass the creds if needed. Need for the load balancer
-
Interesting, will this address be used or will it stay like this to check this issue? - 22 May 2023 (7 messages)
-
It will stay dormant with these utxo’s until the sends are able to process.
Something definitely missing from addrinexrs or something that’s not kicking back the correct values from the sha256 encoding of the hash -
Just an observation and inquiry regarding future steps of further protecting assets and xcp value.
It appears that many artists are issuing numeric assets prior to the big day to stack up assets without xcp fees - creating assets that can be transferred later or re-issued without the xcp burn fee. Inadvertently creating a market for pre-xcp-burn numerics.
Would the next logical step be to impose the xcp burn on re-issuance's and transfers as well? -
Also i added some more notes to this issue. Definitely looks like the source of the Insufficient Funds Error after further validating the records in addrindexrs.
https://github.com/CounterpartyXCP/counterparty-lib/issues/1242#issuecomment-1556259653 -
Morning update: Downloaded 9.60.1 bootstrap from backup, did reparse on it to validate all 9.60.1 data and update database version to 9.60.2.... now parsing blocks to catch up... about 15k more blocks to parse until CP is caught up, at which point Javier and I can dig into the issue and verify if it is a parsing issue or a bootstrap DB issue ... will report here once we know more..... at least another 12+ hours of parsing... Haven't heard of any more issues tho, so seems so far issue is limited to this single tx
-
I've decided. I am happy to accept the role as CIP Editor 🥳
-
That is awesome news JP! I am really happy to hear that! I just sent you an invite to maintain the CIP repo 🙂
-
- 23 May 2023 (5 messages)
-
Joined. -
Heard Counterparty forked?!
-
-
Morning Update: The 9.60.2 reparse completed overnight and I just verified that the missing transaction IS in the 9.60.2 database.... we have no consensus issue... just an issue with a bad bootstrap with a missing tx, and xchain running off that bad bootstrap..... will push new bootstrap in a few, update all xchain servers to use the new bootstrap, rollback xchain to the problem block, then allow counterparty2mysql to reparse the block data from CP into the mysql database.... TLDR... no consensus issues 🎉️️️️️️
-
root@web01:/home/jdog# sqlite3 federatednode/data/counterparty/counterparty.db
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> select * from dispenses where tx_hash='16bd438b1dee6b1f750758eeabef7a876c204082a088c48ca51c416d6651d5db';
2365514|0|16bd438b1dee6b1f750758eeabef7a876c204082a088c48ca51c416d6651d5db|790339|1PUNK1n3ettNssAne1a2uyiqLctYx2jpXt|12TVPcQeLaBuTAehLCgLxAFZYcQDoAQKBi|A10701053519953965000|1|87127f2d169ef1c31eb48ae3f90d8446a708dee8c21ead8288fb52a67031c6e2 - 24 May 2023 (12 messages)
-
Someone explain to me XCP-20?
-
docs.counterparty.io
-
its like XCP but with -20 to make it new and exciting
-
Using burn addresses for 'mints' is a great way to take up utxoset residence -
its an interesting one, because you could potentially add an option to bitcoin nodes to drop utxos sent to a list of burn addresses
-
It’s like 3 levels of memes deep at this point. -
or at least exclude from ram cache. I heard the utxoset is now >10gb so its not like all nodes ram cache the entire thing
-
I chatted with Luke dash jr in Miami and he doesn’t think utreexo is a viable solution to utxo set growth
-
I think filters probably make sense in the short term
-
Did he say why? I’d like to add it to my anti-FUD arsenal
-
Tbh I was so star struck I don’t remember, I think it had to do with memory constraints and requiring too much processing power or something
-
You’d have to ask him tho
- 25 May 2023 (41 messages)
-
Hey I don't know if this warrents a github post, i can do that. But I've doubled checked this and I can't figure it out, I know 'xchain is updateing' but it seems to be past these events. I'm seeing differences between what XCHAIN is saying for JPJA counterparty decoder.
I set up a dispenser yesterday at and address I use often for dispensing 1M5NZzTdDwuKFtKt8tQbK9BstUnkWaUhXi
a little over a week ago I set up a dispenser in this txn 257b11591f0c93cd71564add11144b572696b761f86b51e533ab8a2b2e2855e8
on xchain is shows filled 2 days ago after a long awaited unconfirmed transaction finally cleared the mempool and filled. This worked as expected
After that was complete i set up a new dispenser at the same address in this txn 0e22c022dae34c5738d08b9ccf9353aeb5e56c8553628ecd7d3a7338f1b5293f
The above txn on xchain shows the old price (0.00018 v 0.00027999) AND that the dispenser is closed. I do not see the XCP in wallet but I recieved no BTC. If i look at the txn in JPJA's decoder or on xcp.dev I see the expected dispenser -
-
-
my dispenser is now showing entirely blank on xchain - unlike this screen shot from last night https://xchain.io/tx/0e22c022dae34c5738d08b9ccf9353aeb5e56c8553628ecd7d3a7338f1b5293f
-
and a similiar issue is being reported in the main room
-
J-dog can you please check my dispenser i opened it yesterday and today its dissapeared and asset also doesnt return to my wallet txid : f0bb676495f5f65bdf3ccd3a517f50cb0c6692d9cbda713a0314dfb3f15768ae
-
I have a similar case opened yesterday
-
-
okay waiting patiently then! If someone wants me to test anything (for example attempting to fill my own dispenser to see the behavior) - let me know.. Wish i had more technical skills..
-
-
yes it works on both JPJA and xcp.dev
-
as does the other txnid cases above
-
well JPJA is just a tx parser afaik, it doesnt check validity
-
word, i was using both when xchain was updating
-
i know it showed up there (and still is) while xchain was days behind reparising
-
whats the url for JPs
-
-
gotcha, yeah i wouldn’t use that to check validity
-
noted
-
like i could send a tx with 1,000,000 XCP i dont have and that decoder would parse it just fine
-
yes yes, understood. we've discussed this at length actually (not that I knew that was a limitation of this specific tool) that anyone can just write invalid OP_RETURN xcp txns, and they simply don't work (e.g. spending a larger balance then exists) lol
-
yep exactly
-
don't remember when but I remember when you talked about that and I learned that and it clicked
-
everything matches between xchain and xcp.dev up to blcok 790337
-
after that there’s a deviation and the hashes dont match up
-
my tx: block_index: 791102
dropax tx: block_index: 791168
reagan tx: block_index: 791162 -
yep jdog is just going to need to rollback and reparse from 790337
-
in the meantime just use xcp.dev
-
Okay, great to know I'm not insane or obtuse and missing something. Thank you
-
Bench iamanage to get my assets by buying it from myself from another adress its working
-
they still work, the dispensers
-
True, the tool parses transactions. It does not check for validity (sufficient balance etc). I will put a clear warning on top.
-
xchain rolled back to 790337 ... and parsing blocks to catch up.... tx_list hashes match between 9.60.1 and 9.60.2 ... but ledger/messages hashes are not matching.... and they should... got msg into Javier to dig into why the ledger/messages hashes are different... He is on vaca today, traveling to Italy (on a plane now)... once he gets off plane and checks his DMs (and cries because we are making him work on his vacation)... he will get back to me/us with some more helpful info....
-
Please dig into blocks and txs after 790,338 and document any missing txs or differences in this github issue please.... CLEAR concise posts with tx hash references and details... I don't think we have a major issue, just an issue with some hashes not matching up.... but want to be 100% sure that is the case.... pls help. https://github.com/CounterpartyXCP/counterparty-lib/issues/1240Tx included in v9.60.1 but not in v9.60.2 · Issue #1240 · CounterpartyXCP/counterparty-lib
This dispense is shown on xcp.dev - https://www.xcp.dev/tx/16bd438b1dee6b1f750758eeabef7a876c204082a088c48ca51c416d6651d5db It is not a Counterparty tx according to xchain - https://xchain.io/tx/16...
-
should i wait for the reparse ?
-
or log now?
-
only log issues AFTER this reparse.... we are parsing blocks from 790337+ .... so only post issues for blocks that are parsed now on xchain.... does no good to post about "I had issue yesterday with tx Y in block 791000" when xchain is not parsed up to bhlock 791000 yet
-
if you want to help with debugging... check blocks being parsed for any differences... if your just wanting to figure out about your specific tx.... wait until parse is fully done.... trying to hone in on specific differences here.
-
10 4
-
message index is off
-
thats the thing that stands out immediately
- 26 May 2023 (31 messages)
-
https://forums.counterparty.io/t/fee-on-numeric-assets/6601/3
I'm im favor of adding a 0.10 xcp fee for numeric assets and 0.01 for update issuances (lock, additional supply, change description, etc). This should be a temporary solution to be replaced with a dynamic fee later.
What do you guys think? Should i submit a CIP?Fee 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 like it. XCP has always been regarded as an anti-spam mechanism and it should be used to deter spam when appropriate.
Instead of PoW to deter spam, its PoX, Proof of XCP. Something that proves a participant is in the game & the slightest bit willing to contribute positively to the ecosystem, however minutely. -
I have posted some ideas on counterparty talk
Be keen to hear what people think about adding pubkeys as a section in enhanced asset information
https://forums.counterparty.io/t/enhanced-asset-information-specification/6431Enhanced Asset Information SpecificationThe enhanced asset info spec we have from the founders is good, but is very basic. I have been meaning to write a CIP to extend this asset information to allow for additional information to be specified in a standardized way, but have never got around to it. Now that we are at a point where users are abusing the ‘description’ field on xchain.io and using it to insert audio and video players and other random html, I feel defining the spec is a must. It is clear people want to be able to use a...
-
I also bumped the locking asset description discussion, perhaps that can become a cip as it is an idea that has been around a while and it is kind of expected nfts should be immutable and preventing asset description changes is a step in that direction
-
-
yeah this has bothered me for a long while tbh.
so i was exploring using subassets instead of desc early this year before ordinals broke out.
mentioned it few times in channels but crickets -
but this is when you all were still happy using imgur and shit lol
-
token is the art i know i know 😉
-
I personally dont see a point in locking the asset description... but, clearly some ppl do... so, think we should have the option for sure... I'll add it to BTNS-420 now... see how many ppl use it 🙂
-
The only thing I’ll add is if the goal is to stop spamming of A assets soon as possible by using XCP as a price deterrent, the higher fee the better.
A 0.1 XCP fee will take 2.5X longer to accomplish than a .25 XCP fee and 5X longer than a .5 fee.
The X is based on the assumption that XCP is only going to gain value because of burning and not demand.
If XCP gains value because of demand instead of burning, that works as well.
That’s my thoughts, I don’t care what fee you guys decide. -
It is stupid an A asset would cost the same as a named asset though.
-
I'm not sure this is useful, you have all the history of your asset descriptions
-
Not done with the spec.... prolly wont be for another couple weeks as I refine it and such... but I believe I did a decent job of carving out all the ACTION commands we would want.... I hope I dont have to build out all this BTNS functionality... but, if we going down this crazytown rabbithole.... might as well establish the terminology used in CP and get them familiar.... vs letting a new square-wheel get invented.
-
Anyway... here is first draft.... off to work on the indexer for a bit... but figured i'd share in here first... will drop publicly in a few hours... feel free to share thoughts... will be back in a bit to check in
-
Broadcast-Token-Naming-System/docs/BTNS-420.md at master · jdogresorg/Broadcast-Token-Naming-System
Broadcast Token Naming System (BTNS) specs, docs, and tools - jdogresorg/Broadcast-Token-Naming-System
-
It could be displayed as latest descriptions + historic descriptions in an explorer (showing the last one only is a choice)
-
yup its all social consensus. With Bitcoin Stamps, we only consider the first Description "minted" to be valid and ignore all changes. The same sort of happens with Green banner series. In my opinion, this is the way, though opinions may differ. I like the "immutability" aspect of ignoring changes, because they aren't really "changes" they are additions to the blockchain. They are only viewed as "changes" when the UI presents it that way to users.
-
Imgur is not happy with NFTs using using it I thought I heard someone say on one of the Miami conf videos
-
indeed you do have the history, I thought it may be a nice option like a issuance lock it's not mandatory for all but some use cases it may be nice
-
Bit rot is real and locked descriptions could lead to tokens with broken images that can't be updated via an addition to the blockchain.
But on the other had updating ones 'rarepepes' is a exercise in futility as additions would be ignored by most and its only those looking closely at the token history would see anything
Even image data on ipfs can be lost, stamps are the most resilient of that there is no doubt.
Token creators/artists see things differently to end users for sure, I know some people are surprised when they learn that a creator can change the description on a 1/1 locked token, as they are not aware the lock only applies to issuance quantity. I know this is all explained in the docs but we saw only yesterday people are not even reading the red header warning messages displayed on xchain whilst it was re parsing
Burning ownership is always an option, and is in keeping with the counterparty project ethos but is not as readily understood by end users not ofait with all the nuances of the tech and label definitions Counterparty uses
I agree they are not 'changes' but are additions to the asset as its history is always available.
Social consensus is just as important as the tech and is just as much a part of the ecosystem as a whole
I am just sharing ideas here -
this is insane...😂 -
JDOG.xcp (@jdogresorg) on X
Today I am proud to announce the "BTNS Token Standard (BTNS-420)". A new token standard for issuing tokens via broadcast messages on #Counterparty https://t.co/esr5wNPoQR Indexer, Explorer, APIs, Wallet, emblem vaults... soon🚀🚀 #LFG $XCP #XCP20 #BTNS #BTNS420 #BRC20 #SRC20
-
How does BTNS-420 stack up against BTNS and XCP-20 ?
-
XCP-20 is by far superior... its features work right now
-
BTNS uses DEPLOY/MINT/TRANSFER (ugly nonsense from BRC and ETH mindset)... BTNS-420 is backwards compatible with BTNS... but uses ISSUE and SEND instead of DEPLOY and TRANSFER (smaller word, less to encode, less expensive).... BTNS-420 features dont work yet... just are described how they will work
-
so... if you want something that works right now... by far... Counterparty and XCP-20 are the way to go!
-
If you want to fuck around and play with some crazy features like "PAUSE", and "RUG" and "CALLBACK" and see what kinda nonsense you can get into with this new token platform, before it gets all "serious" (will try to keep it light and experimental always)... then maybe BTNS-420 is for you 🙂
-
Was going to say burn, but burn is just transfer -
I’ll have desktopcommando make weird stuff, he’s the one that sent a vault to itself, making an uncrackable knot
- 27 May 2023 (47 messages)
-
Joined. -
Im all for allowing locked descriptions. People will use it in smart and dumb ways, but that's the nature of experimentation. The protocol 's purpose is to make this possible.
I personally think of the url as a temporary pointer and the hash as permanent. Description should include both, and the hash will have precedence in case of mismatch. -
In the meantime its possible to lock both description and supply in one fell swoop by transferring ownership to a burn address, have been experimenting with this for XDP20
-
Excite
-
True but you cut off any opportunity to make subassets at the same time.
-
ans/or to sign txt message with address
-
Stop fednode, remove fednode/data/Counterparty/*, then start up counterparty again… by default CP downloads the bootstrap database so you can get up in a few hours…. Sounds like your doing a full parse, which could take weeks
-
-
I've fallen behind on reading all this for a couple weeks now, and have not commented due to the volume of unread messages. I'm still catching up, but at a high level my opinions are not changing. These are nothing more than suggestions for a path forward as Counterparty evolves. -
my hot take is that Counterparty development priotities should be, in this order:
1 Formalize a process for making protocol level changes, adn stick to it. Ad hoc consensus gathering in a chat room is far from ideal, and not in line with best practices for FOSS projects.
2 Shore up the most pressing design shortcomings. For example, the database needs redesign and should probably be migrated away from SQLite anyway. It's a big but imporant task, and requires refactoring some of the glue logic that interacts with it as well. This is a major upgrade that is years overdue.
3 Update and maintain a reference implementation of a Counterparty wallet. It is inexcusable for us to rely on 3rd party wallet software, but that's the status quo because the standard client does not support features that were added years ago like dispensers. A protocol needs a reference implementation which implements ALL features, and it should get updated to support 100% of new features every time. This is valuable to both core devs and 3rd party developers who look to it as an example.
4 Attempt to improve governance! Counterparty needs a more decentalized process to resolve conflicts in a binding way. I have no idea what the solution is here, but we could sure use one if anyone has ideas.
5 Maybe push tons of code changes to implement shiny new fad features after the rest gets done. -
^^ take with a few grains of salt, eh?
-
Joined. -
I agree with pretty much all of this, but the biggest pressing need is developers to actually implement these things
-
ditto.
it's understandable based on the niche users for years basically resulting in CP being a hobby project for everyone.
another way to look at this is to start over and pull in the best of CP and re-implement more efficiently, borrow from current trends where appropriate and put out a new ref client that is top priority for upkeep.
it can even be rebranded at this point.
and I know BTNS is probably something like this so maybe that is actually the start of this new phase. idk. -
someone reminded me that I own COVFEFE asset from 6 years ago.
i'm considering doing a test as a so-called XCP-20 dispenser like FLOCK...
but not a full burn. a half burn. half goes to development funds.
i admired the XCP proof of burn but times have changed and this project needs funding. learning from the past... i see no reason to entice ppl to burn btc while CP needs dev funds.
COVFEFE is just a fun asset to use and on May 31 it will be 6 year anniversary of the famous Trump tweet turned meme. -
alternatively, I can try to sell the asset and donate the funds.
-
and anyone else with interesting old assets could also do the same.
-
#HALFBURN
-
would need two dispensers
-
the burn is just marketing
-
send to satoshi address
-
the other dispenser sends to agreed upon address for proper handling of dev fund
-
we could request other good asset names for same purpose.
-
idk wtf FLOCK will be used for or COVFEFE etc but thats besides the point
-
i guess
-
all i know is, posting a donation address doesnt excite anyone
-
meme it
-
get some art work mixed in too
-
haha yeah, just a thought.
-
so many assets sitting around doing nothing
-
some of them are pretty good
-
I do have BURN as well
-
ideally funds would primarily be used to get a few more dedicated developers in the mix.
-
fresh eyes is a good thing
-
could also do a sort of $BAG
-
well, Emblem Vault is our friend
- 28 May 2023 (27 messages)
-
xchain not updating?
-
xchain back up... had an issue with parsing due to someone using an 4-byte UTF-8 character.... fixed now
-
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)
-
noobie question, as I was today testing to lower the multisig dust size in freewallet, what role does the value in CP api play in the process? (as by being set in freewallet the different outputs have that value)
-
freewallet allows you to override if you want... but default is still 7800 in CP.. and freewallet doesn't override CPs default fee unless you manually go in and do so.... So... even tho freewallet has ability to adjust multisig dust level, most still use default CP fee of 7800 sats... this PR reduces the default in CP to 1000... instantly benefits everyone using multisig
-
Thanks 🫡
-
So it affects to the fee calculation even if you set a value in freewallet, no?
-
(I'm finally starting to try to actually learn things, checking counterparty code and so on 😅)
-
-
-
using 900 as dust, so 7 outputs
-
-
but then the fee is higher than 0.0004
-
I dont do fee estimates or tell you what fees to use.... that is on you
-
I do plan to get better fee estimation in freewallet
-
fee estimation in freewallet is based on AVERAGE send which is like 256 bytes or something... so horrible way to do fee calculations... just never got around to finding time to fix it yet.... always something else to work on
-
so the fee set in there is not supposed to be the final fee for the transaction, no? I think that's the obvious thing I am missing
-
but yeah... fee estimates in freewallet are fine in most cases, cuz the txs re small.... but for larger txs (multisig, and MPMA)... fee estimates are way off, so need to figure that stuff out on your own at this point... I just pay a way high fee on stuff I want to get processed and it usually works fine... worst case, I underpay and can accelerate tx or just wait
-
freewallet-desktop/html/fields/tx-fee.html at master · jdogresorg/freewallet-desktop
Desktop wallet for Win/Mac/Linux which supports Bitcoin and Counterparty - jdogresorg/freewallet-desktop
-
tbh I have always overpaid myself by a lot because a) I don't have patience and b) I don't have patience haha
-
fee in freewallet is based off a hardcoded 265 byte tx (average size of a send)... will be WAY more accurate when I put actual slider in there with sats per vbyte... then do pre-filight check with CP API to generate tx, see actual size of tx, then adjust fee appropriately
-
Thanks for the info!
-
I believe dust was set so high to give an economic incentive to redeem.
-
Imagine someone obtains Mike’s keys and updates the description of RAREPEPE to “Kill Jews Man”
This single scenario is enough for me to support this update. -
Perhaps my #5 is just giving short shrift to the goal of staying relevant. Shiny new features may attract developers, and it's difficult to think of better strategies to attract them. What do you think would help?
-
Same lol
- 29 May 2023 (15 messages)
-
It was only after I had made a dozen or txs that resulted in multisig encoding that I noticed a lot of satoshis had gone missing... so I educated myself and was able to reclaim them
it makes sense to use smaller dust outputs if you have zero intention to ever reclaim .. or if your using keyburn
I am still using 7800 sats on multisig encoding when not using keyburn as I do reclaim those satoshis -
Database changed
mysql> select count(*), sum(length(description)) from issuances where description like 'stamp:eyJwIjogInNyYy0yMC%';
+----------+--------------------------+
| count(*) | sum(length(description)) |
+----------+--------------------------+
| 22655 | 2042884 |
+----------+--------------------------+
1 row in set (0.39 sec) -
Just a friendly heads up... the SRC-20 spamming issue continues... now at 22k non-usable numeric assets spammed... Need for fee on numerics remains... SRC-20 devs still spamming numerics... going on 3+ weeks of "give us time to pivot".... #JustSaying
-
@jp_janssen What are your thoughts? How close are you on CIP29?
-
Also would appreciate your thoughts on this topic. https://forums.counterparty.io/t/remove-unusable-assetsRemove unusable assets
The database is now bloated with 22,000+ numeric assets which have been issued with no supply and locked. There is no meaningful way for these assets to ever use the Counterparty system, and this data just bloats the assets table, making queries slower for assets and users who ACTUALLY use the Counterparty system as it was meant to be used (token supply issued for asset) I propose that we remove/purge all numeric locked assets with no supply issued from the assets table. A record of the issua...
-
I will add cip29 to github tomorrow.
-
When do you feel it should be activated? Can you also please suggest an activation block that you feel is appropriate? (I believe community consensus here was 1 week is enough time... but your CIP, so your call sir 🙂
-
My impression is that a majority is for an xcp fee on numerics. Releae CIP tomorrow, wait one week to fork unless any technical objections. Activation block another N blocks after that (dunno what's the norm there)
-
the "fork" happens when the block is activated FYI.... so, would prolly get put out CIP, put out release tomorrow with activation date for 1 week... then in 1 week the "fork" activates
-
my hot take is that Counterparty development priotities should be, in this order:
1 Formalize a process for making protocol level changes, adn stick to it. Ad hoc consensus gathering in a chat room is far from ideal, and not in line with best practices for FOSS projects.
2 Shore up the most pressing design shortcomings. For example, the database needs redesign and should probably be migrated away from SQLite anyway. It's a big but imporant task, and requires refactoring some of the glue logic that interacts with it as well. This is a major upgrade that is years overdue.
3 Update and maintain a reference implementation of a Counterparty wallet. It is inexcusable for us to rely on 3rd party wallet software, but that's the status quo because the standard client does not support features that were added years ago like dispensers. A protocol needs a reference implementation which implements ALL features, and it should get updated to support 100% of new features every time. This is valuable to both core devs and 3rd party developers who look to it as an example.
4 Attempt to improve governance! Counterparty needs a more decentalized process to resolve conflicts in a binding way. I have no idea what the solution is here, but we could sure use one if anyone has ideas.
5 Maybe push tons of code changes to implement shiny new fad features after the rest gets done. -
I think we should at the very least attempt his first point here
-
Afaik we don’t have a defined process, good opportunity to define best practices
-
I agree. How do we define this process and get it approved quickly? I am 100% supportive of a formal process, which we can follow on releases... makes all of our jobs easier to have clearly defined processes to follow.
Do we have a basic framework for this FOSS best practices that we just need to approve? or are we starting a longer "it would be great if it worked this way" idea conversation?
While I am supportive of a process for releases, I also feel getting a fix to the numeric issue out the door ASAP is important... waiting a day or two on a formalized FOSS process is no big deal... but, honestly, not sure we will be able to hammer out a FOSS release process everyone is comfortable with quickly.
All that is to say... Lets move forward on an FOSS release proceess... but, if it is not clearly defined in 24-48 hours, I still think we need to move forward with the fee on numerics (so it activates in a week)
Also, should go without saying but i'll say it anyway... this is a community project, and I have never, and will never put out a release without general consensus of the community (no one agrees 100% ever) -
I would suggest the following guidelines as a base framework for releases :
- All protocol changes should be defined in a CIP
- 1 week as discussion in forums to gather ideas for CIP
- 1 week as CIP for people to review/discuss idea and refine CIP
- 1 week as Pull Request (PR) for tech people to review the code and test
- 1 week activation block for new release in feature
Using the above guidelines, an idea can go from Idea -> Discussions -> CIP -> Code/PR -> Release -> Activated feature all within a month (4 weeks).
I feel this is long enough to give ample time for people to weigh in on improvements and not "rush" anything but emergency fixes into release.
Tho.... there will always be a need to put out "emergency" release which bypass this process (like when CP chokes and is hard-down... needs to come back up ASAP, no time for talk, just time for fix issue)... But those situations happen very infrequently (3-4x in the entire existence of CP) - 30 May 2023 (61 messages)
-
https://github.com/CounterpartyXCP/cips
Just added CIP29 - Asset Issuance Fees.
- unchanged fees for regular and subassets
- new 0.10 xcp fee for numeric assets
- new 0.01 xcp fee for other issuances
- no longer save invalid issuances in the DB
Whether the last point is feasible must be addressed. I raised a github issue.GitHub - CounterpartyXCP/cips: Counterparty Improvement ProposalsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Hi JP. By "no longer save invalid issuances", you mean 0 supply issuances ?
-
invalid issuance in counterparty terminology can be if I try to register a asset that already exist, or to update a asset I don't own ... my issuance would be invalid as I don't have authority to update someone else's asset or to issue more supply of a asset I didn't initially issue
a 0 supply asset is not invalid as I understand it ... but I could be wrong? -
cp api seems to not perform sanity checks on a create issuance tx construction, allowing these 'invalid issuance' transactions to be created, signed, broadcast and mined at which time counterparty then deems them invalid
-
Correct, also invalid if issuer's xcp balance < fee.
0 supply is valid. -
Could a 0 supply for numerical assets be considered invalid? It would solve most of our problems 🤔 (but it needs to stay valid for sub assets)
-
Should it be cp api refuses to generate a issuance tx if the xcp balance on the address is < fee, that would seem logical
-
0 supply can be useful. Eg I have contemplated making a meta verse land like Etheria. Would have asset ownership represent land plot, where asset owner updates description to build on the land.
-
Maybe there is a reason CP API allows the creation of what CP thinks are invalid transactions?
Sure you can craft a tx over the api then add xcp to address before broadcast but no one is doing that
why are 'invalid' transactions allowed to be created?
I guess 2 person's could try to register same asset in same block ..the one with highest fee and higher in block is valid and the second one is not .. but that's different to a tx that is invalid before broadcast -
Yeah I have some too, but as assets or subassets
-
I'm not sure it makes sense to have 0 issuances as purely numerical
-
what happens if you issue a numeric asset with a supply and then destroy it down to 0 .. does it get deleted?
-
-
It would stay. Imo the problem is the first issuance.
If you need + 2 transactions to get your SRC shitcoin instead of 1 broadcast, it would move people to broadcast -
There is a miss match between jdogs address in the linked json and the issuer of the BLCKBOX asset too
-
Should it be a 0 supply issuance plus a lock on a numeric asset in a single tx that is outlawed ? as that would then need a separate tx to lock a 0 supply numeric, causing requirement of 2 transactions moving people to broadcast ?
as taproot wizards have demonstrated protocol changes can have unintended consequences so its good to think things through from different angles -
There’s been a lot of focus on numerics with zero issuance but stamps guys could easily just add an issuance amount and never use it to bypass any roadblocks set for zero issuance assets
-
Yes, and perhaps burn the tokens, adding more bloat to the db.
-
What we don’t want to do is create a protocol change that does this
-
-
Wouldn't it defeat their "protocol"? They would be creating 2 coins or something
-
No they’re just storing arbitrary data in Counterparty they don’t care about the tokens they’re creating to do it because they’ve got their own tokens
-
Allowing them to stick to zero issuance numerics and focusing on database optimization instead might be a better course of action, the worst thing is we make Counterparty less usable AND it doesn’t stop spamming
-
Fork risk is also ever present
-
I'm liking more and more the idea of a BTC fee like proposed by nishseq
-
If named assets are XCP fee, numerical could have a -much higher- BTC fee
-
It would stay "only BTC" and prove the utility of XCP
-
There already is a btc fee in the form of Tx fee
-
Plus this isn’t really the issue, it’s src-20 that’s creating bloat
-
What if instead of restricting we simple add an open mint feature to issuances and make them irrelevant
-
The xcp-20 narrative experiment was pretty successful after just pushing it for a day or two
-
@jp_janssen You bring up a good point, however stuffing issuances into the issuances table at this time is not an issue that needs addressed. Perhaps at some future time when we have a case where someone is spamming invalid issuances with HUGE descriptions, then we can tackle this issue.
IMO we need to keep invalid issuances in the issuances table in order to determine and relay the status of the transaction to the user (CP determines state at time of execution of action, and saves state... valid, invalid, etc) Without saving invalid issuances, we would have no way to know the state of the issuance, nor why it failed, and looking that information up retroactively would be difficult (to determine state of balances at time of issuance execution).
The benefits of being able to easily see "Oh, my issuance failed because I ran out of XCP, let me send my address some more XCP" is more helpful than hiding this failure entirely from the user.
I oppose this change at this time, as I feel it requires more discussion before being implemented in a CIP. -
TLDR... fee on numerics and on issuances is what I am supportive of at this time... not changing what data we store in the database.
-
@jp_janssen if you remove the no longer save invalid transactions to the issuances table. requirement... CIP looks good to me
-
I was of the impression that the issuances table is more problematic. (?)
If we allow invalid issuances to be saved, the SRC guys can still use this table for data storage , still without xcp fee.
Only improvement is that a new row won't be saved to the assets table. -
Either way, my view stands... our issue is with ppl using numerics because they are unfairly cheap in comparison to other XCP assets.... fee on numerics solves that issue and puts fee on all assets... your addition of an fee on each issuance is also a good idea and I am supportive of it.... but, cant be supportive of changing what data we store in the database without more discussions.
-
if this is a sticking point, then I oppose this CIP
-
Replied github. I agree, can remove not saving invalid tx condition. Fee still a net positive
- prevents flooding assets table
- discourages flooding issuances table (assuming they're not ok with status invalid)
- easy for explorers to filter out invalid issuances
Whether saving invalid txs to XCP DB should be a separate discussion/cip -
The funniest part about src20 is that when they finally enable transfers no one is gonna want their bags
-
I have come to agree with adding a fee to numeric assets, but just because it connects it even more to Bitcoin. XCP is burned BTC. Assets should all be burned XCP then.
And I would keep it simple, same fee as subassets (which are numerical assets). Maybe take the opportunity to reduce the fee for these…
I would do nothing else. No additional fee for more issuances. No messing up with the protocol architecture.
BUT before all this, I would fix the issuance message id. -
i agree with juan on this fixing issuance message issue at the same time as adding a numeric fee
-
since they’re both consensus related
-
What is the issuance message issue?
-
Even Juan’s in agreement
-
Still, I think if the goal of the fee is to reduce spam asap, it should be 0.25 XCP, 0.1 only delays the result.
But whatever, it’s great to see Juan on board. -
0.1 for subassets too would be better
-
Issue is that numerics fee needs to go out fast... and other fixes need testing
-
Issuance backwards compatibility by pataegrillo · Pull Request #1226 · CounterpartyXCP/counterparty-lib
New message type for new issuance format Old issuance format (with callability parameters) will be parsed as well as the new one
-
If we are going with the "this is a protcol change, lets put other protocol changes in"... then why not this one as well?
-
allow triggering of dispensers by all tx outputs, not just the first output by pataegrillo · Pull Request #1222 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
very quickly can see how now we kick the numerics can down the road... Lets address this ONE issue which is a problem NOW... then address others issues with more testing... holding off on putting a fee on numerics NOW seems like a mistake.... we know the SRC-20 spamming is going to continue... database growing... at least make it cost more to spam CP... NOW.
-
Yes... Juan adds value, and he should be here... no one kicked him out... he choose to leave because he didnt like ppl telling him to stop screaming when ppl dont like his suggestions.... He is most definitely welcome back here... would be nice to not have to play telephone game 😛️️
-
The difference here is that both of these protocol changes involve issuances, but I get your point and def don’t wanna rush anything that needs more testing
-
ok... please test the PR... we have had it ready for 2 months... but I have had no time to test
-
Issuance backwards compatibility by pataegrillo · Pull Request #1226 · CounterpartyXCP/counterparty-lib
New message type for new issuance format Old issuance format (with callability parameters) will be parsed as well as the new one
-
also... if we are messing with issuances... we have a couple issues related to asset description as well
-
wont spam them here... but... prefer we deal with all issuance problems at one time and not lump them with numeric fees... but defer to you
-
This change simply reverts old issuance and creates a new id for the new format?
-
yes... supposed to
-
agree... elephant in the room is the db schema. stop defensive and go to root of problem.
- 31 May 2023 (171 messages)
-
As requested by @jdogresorg i have opened a issue on github so that everyone can now create invalid transactions on a @jp_janssen asset as was seen in the wild recently
-
@B0BSmith Glad you were able to track down the specific issue.... we will get it fixed.... pls link the github issue here 🙂
-
@hodlencoinfield PR for fee on numerics is ready for testing whenever your done testing the issuances/format fix PR...
-
Numeric asset xcp fee by pataegrillo · Pull Request #1237 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
LMK when your ready and i'll put the PR on web01 and you can continue testing there.. thx 🙂
-
Create invalid transactions with CP API
https://github.com/CounterpartyXCP/counterparty-lib/issues/1245Skipping asset owner sanity check on numeric asset issuances · Issue #1245 · CounterpartyXCP/counterparty-libThe payload below can be used to create an "invalid" transaction using the CP API { "method": "create_issuance", "params": { "source": "1JDogZ...
-
So this is strictly an API issue?
-
yeah .. api allows you to makes a tx that after mining is deemed invalid
-
see this tx as example of issue in the wild https://xchain.io/tx/2317041
-
@hodlencoinfield I updated the CP API github issue with easy to reproduce test cases.... confirmed yesterday, we dont do owner address validation on numerics before allowing issuance to be created.... need to get that fixed... should be simple tweak 🙂
-
gotcha, well at least counterparty-lib is catching it as invalid
-
yep... now to prevent ppl from wasting BTC fees on a tx which will fail 🙂
-
a fix will also prevent people from posting issuance data to other people assets ..as the invalid tx is listed on the xchain issuance tab of the asset
https://xchain.io/asset/A2222222222222222222#issuances -
eh... kinda... it will prevent CP API from generating the tx... anyone can still roll their own TX and get their issuance listed as invalid... but def a step in the right direction 🙂
-
ahh of course, the bar is raised by the fix, rolling one's own raw cp txs is something i still aspire to, need to spend more time with JP J electrum tools
-
I broke counterparty with a raw tx once. Reason was that sanity check was in the API which i bypassed.
After that i"ve only tested on testnet. My electrum tool supports testnet btw. -
It was never intended that your asset got stamped with an invalid tx, The idea was to match the asset_id to the dust return pubkey used for keyburn which was known to work as a named asset with a keyburn had already been stamped and was valid
Official Counterparty Dev Chat
Public archive of Telegram messages.
- 03 May 2023 (25)
- 04 May 2023 (31)
- 05 May 2023 (12)
- 06 May 2023 (6)
- 08 May 2023 (14)
- 09 May 2023 (169)
- 10 May 2023 (20)
- 11 May 2023 (90)
- 12 May 2023 (16)
- 13 May 2023 (160)
- 14 May 2023 (144)
- 15 May 2023 (515)
- 16 May 2023 (97)
- 17 May 2023 (141)
- 18 May 2023 (27)
- 19 May 2023 (156)
- 20 May 2023 (73)
- 21 May 2023 (41)
- 22 May 2023 (7)
- 23 May 2023 (5)
- 24 May 2023 (12)
- 25 May 2023 (41)
- 26 May 2023 (31)
- 27 May 2023 (47)
- 28 May 2023 (27)
- 29 May 2023 (15)
- 30 May 2023 (61)
- 31 May 2023 (171)