Biggest stamp of all:

https://bitst.art/A1888888877444444444

Full list of assets with longest descriptions (by first letter):

A
[{"asset":"A1888888877444444444","maxdesc":10338}]

B
[{"asset":"BLCHALLENGE","maxdesc":8580}]

C
[{"asset":"CHIKENBRAIN","maxdesc":1318}]

D
[{"asset":"DANKSTAMP","maxdesc":758}]

E
[{"asset":"EIFFEL","maxdesc":522}]

F
[{"asset":"FLAMP","maxdesc":2542}]

G
[{"asset":"GOODDOG","maxdesc":2602}]

H
[{"asset":"HOMERSTAMP","maxdesc":562}]

I
[{"asset":"IHEARTTRASH","maxdesc":133}]

J
[{"asset":"JESTERLENNY","maxdesc":176}]

K
[{"asset":"KAMOTOS","maxdesc":210}]

L
[{"asset":"LITTLELEAGUE","maxdesc":502}]

M
[{"asset":"MAYAJALOTE","maxdesc":671}]

N
[{"asset":"NIATCOIN","maxdesc":1808}]

O
[{"asset":"OLDVIRUS","maxdesc":130}]

P
[{"asset":"PERMANOISE","maxdesc":5542}]

Q
[{"asset":"QUAKES","maxdesc":178}]

R
[{"asset":"RAREBTCSTAMP","maxdesc":966}]

S
[{"asset":"SSTAMPEDE","maxdesc":2318}]

T
[{"asset":"THESTAMPEPE","maxdesc":1546}]

U
[{"asset":"UFOPEPESTAMP","maxdesc":482}]

V
[{"asset":"VGSUNFLOWERS","maxdesc":438}]

W
[{"asset":"WRCWAT","maxdesc":194}]

X
[{"asset":"XCPTXT","maxdesc":3870}]

Y
[{"asset":"YOUNIVERSE","maxdesc":227}]

Z
[{"asset":"ZIPPYSTAMP","maxdesc":418}]

Many are less than 200, then there are a couple around 500, then the ones above 1000.

Based on this I would say 500 is a nice round number to limit description lengths, but we could go as low as 200

Will you write a CIP?

Didn’t have that in mind, but I could help you co-author if you are interested

That would be perfect. I won't have time for this until Friday 12th though.

Cool just let me know!

It is a known bug that inscription numbers have skipped many transactions, but now there is an inscription without a sat attached to it! 😆

I released a tool for increasing the off-by-one error: https://github.com/supertestnet/breaker-of-jpegs

Please follow the installation and usage instructions and let me know if it works for you

There is no sat to be inscribed. There is no inputs, outputs, or fees!

https://ordinals.com/inscription/c1e0db6368a43f5589352ed44aa1ff9af33410e4a9fd9be0f6ac42d9e4117151i0

https://mempool.space/tx/c1e0db6368a43f5589352ed44aa1ff9af33410e4a9fd9be0f6ac42d9e4117151

Yet the explorer is showing like if a sat was inscribed

I made the list!

What do we think about SRC-20 in this chat? Has this chat forked yet or are we all running the same code?

@uanbtc @jp_janssen @krostue @B0BSmith I’m not in Miami but curious if any of you OG’s are in attendance and planning on sharing your thoughts while there.

Im unfortunately not in Miami

That’s not a bad thing. Miami is a strange town.

i was there last year. maybe next. not this time tho

@uanbtc what do you think about all of this src20 stuff?

im gathering my thoughts before i share them. Still catching up in various chats. been busy offline the last few weeks.

Which one is yours?? You know you stampers are breaking the protocol 😆. Just be sure to spend the utxos and then I won’t care that much 😉.

Counterparty is beyond repair in my opinion, technically in some way, but more in the politics of it.

Not in Miami this year

I don’t like any of the Xrc20, BUT I do like that they uncover the true intentions of many. At least XCP had to burn BTC to exist, but anything that a simple text file can issue “assets” is just a bitcoin stealing scheme in my opinion. The reality is many don’t care about the ethics of their actions as long as they can profit so I’m not sure what can be done other than educating people.

I saw a video from Bitcoin Mechanic a few days ago that he made a great argument about the dangers of these out-of-thin-air tokens gaining market value makes the fees required minimal in comparison to what they can gain, so the incentives misalign with fair Bitcoin use. He also made some arguments I don’t agree with though 😆

https://tokenstamps.io/collection/named-bitcoin-stamps/150 not locked or in a collection. I’m not chasing a return. Just playing and learning.

This can be checked with the block hashes… and these were consistent until yesterday.

The protocol leadership once again made a hard fork without the due process that said changes should have. Case in point why I believe the protocol is beyond repair.

BUT it will still “work” as long as the users all follow the same transactions ledger… just know that is is fully centrally controlled. And most don’t care I’ve learned.

Thanks for the straight talk answers.

It is a pretty one I like it!

I was ok with burning the UTXO for immutability. I’ll think about it though.

The immutability will stay. Is about not keeping the dust sats of the data-embedded multisig outputs.

I’ve always thought that actually using dust is counterproductive because then those sats have LESS incentive to be claimed…

Wasn't the fork canceled?

The video: https://youtu.be/IFYIaV3iKfc

The latest “minor” release is generating different hashes since block 790339 (yesterday). So it was technically a hard fork change.

What was canceled?

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

Wow! What caused the different hashes?

Block hash the same, ledger and txlist is diff

Gmm hope You don't mind me inviting myself. ( for transparancey, I am Arwyn.)

No invitation required! Welcome

Im also interested in learning which transaction caused it…

Some care. 🐸

@mikeinspace @Stampchainofficial welcome smart frens.

And @reinamora_137 cant forget you

Happy to see people joining, welcome!

I like how your page shows all tx in a block. Are all TX’s hashing differently from that block forward?

I literally did this and it was the precursor to the current Stamp approach as Freewallet had a 200 character limit on Desc but not Broadcast. The reason we went with the current approach is that it’s simpler and Counterwallet was “good enough” with no Desc limit.

You can see the broadcast version here: https://xchain.io/asset/ONCHAINPUNK

The idea being that the asset Desc would reference the tx hash of a base64 broadcast.

Thanks for providing an example. That is super helpful with these technical topics. @uanbtc .dev is great, especially because it shows the important data. https://www.xcp.dev/asset/ONCHAINPUNK

Vs https://www.xcp.dev/asset/GOODDOG

This is actually really helpful. We were under the impression that this was an "easy fix" that would be deployed "shortly" when really it seems far more foundational to the architecture

I’ve run into a similar issue in the past with a lead developer using fields for multiple purposes. Your experience shows that wallet support is a big factor with cp, not the protocol.

The duplication of the description means certain actions like increasing supply becomes cost prohibitive

Sounds like ‘description’ might need a fork.

All it means is that from that block on there is 1+ transactions that nodes are interpreting differently. The rest of the transactions are fine, but is obviously a problem in terms of consensus moving forward

I really appreciate the positive comments towards xcp.dev! These are what motivate me to continue improving it… 🤓

This is great. I did not know about this functionality. Where is this in the spec? Do both transactions have to be in the same block to function?

Yep see it https://www.xcp.dev/tx/efc9ad4ef56d45811777b29fe370900e5de1dd71746448d067e5d92e7361fae8

It’s been a hard road but I’m glad people are realizing what I’ve been saying all along 😂

yeah I hex encoded it as well which was dumb. It was only because xchain was stripping characters from the base64 so Hex-encoding sort of "preserved" it

And is also an unintended consequence of the change of doing LOCKs by description instead of adding a new field like they are done now

Unfortunately with the introduction of the “reset” the denormalization of the data was set in stone. The only way to fix now will require taking all reset assets out of circulation

Is not part of a spec that I know of, but I s just possible to do without any change to the protocol

Lol yeah just keep the base64 data url format directly

I’m having a hard time believing that anything stored in the description field is parsed in any way other than text. It’s a great thing currently but damn that is a big deal. Is the description field the only counterparty field with those behaviors? I need to play on testnet more.

From jdog in the other chat a few minutes ago… 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.

Description is text. Maybe you are referring to behavior in FreeWallet? That is separate product that uses Counterparty, but if you have your own node you make an issuance transaction with utf8 text in the description. That’s it.

This won’t solve anything if these people are already running their own nodes. Also the fee would only apply to the first issuance, that doesn’t stop them to continue making issuances in the same asset afterwards. And even after the fee fork, people trying to issue without XCP would still store all their data in the counterparty-lib protocol SQLite DB, but it would just be invalid.

But I’m not surprised with the decision as it is being evaluated from the perspective of a service provider’s effect of the issuances boom. At the protocol level, almost nothing changes by adding an XCP fee to numerics.

My comment may have been lost in translation but thanks. I’m speaking from a security and ‘soul guarding’ perspective. Brave to parse that base64 into an image. You can embed HTML into a SVG. I was about to do some neat HTML embedding until fees jumped through the roof and people started attacking stamps.

Xchain literally parses the base64 or image pointer in a description.

I asked jdog for an example tx of the blank asset issuance… https://www.xcp.dev/tx/71b9832888082c9cb134fee08936ab9fb4461d71f25d754127d78fcde6afef38

The following asset can help a lot in understanding what is actually happening at the protocol level. This is how the protocol detects and stores issuances, even if they are invalid.

I present to you, the first reset asset:

https://xcp.dev/asset/TWERK

@uanbtc gets it

There’s a lot of zero quantity issuances. This is what anyone that just wants to register a name would do. I don’t see anything wrong with these…

He says zero quantities are created with EVERY transaction?!?

Meaning most of the new numerics are 0 quantity… yeah in these cases they are most likely spam lol. But is the same in ordinals and brc20.

I’ll say it again, a protocol decision is being made based on how xchain shows the data, even though the protocol itself won’t be protected that much.

Some can agree with that, but xcp.dev won’t be changed to only show valid. xcp.dev is an interface to the protocol data, straight. This is what anyone that wants to learn about the protocol (devs) would prefer, not hiding (or adding non chain) data like xchain does

thx for having me in the chat. looking forward to contributing!

Have any of you used the unpsent_tx_hash field on the create_send or create_issuance calls? I"m having issues with that. it doesn't seem to work when i select a UTXO thats not part of a chain that is not part of a chain that has less than 25 trx.

or on the other hand it doesn't appear to select that specific UTXO when i get the insufficient funds error.. super annoying

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 some legitimate usage, like 1/1 collections.

Full reasoning in the forum: https://forums.counterparty.io/t/fee-on-numeric-assets/6601

An XCP fee to solve spam is relative. Spend time in advertising and you soon realize that as far as accounting goes, advertising is in the same column as taxes, fees, permits, commission paid, protection, insurance, payoff, settlements, bribes etc. if the benefit outweighs the effort, that’s literally the ‘cost of doing business’. Only implementing a fee is not the solution to stop spam, thats a way to drive XCP into the hands of scammers, spammers, squatters and hoarders. Postage doesn’t stop junk mail and long distance charges didnt stop telemarketers. Junk mail technically helps subsidize the cost of mailing your birthday card.

The key is to discourage "spam" and incentivize usage of broadcasts over issuances.

I saw great potential for counterparty as very useful tool for the world but it is becoming clear to me that counterparty may need to remain in the realm of collectibles without the equivalent of a major version upgrade. Fun for play, not too ready for enterprise. If not careful, another L2 will fly right on by XCP with the boost of a well executed L3. I’m a digital notary, miner from 2013, maxi and more FWIW. Fees change little about spam and is a reactionary action. Is there a more proactive approach? The self adjusting fee sounds about like the best option, if one must include a fee to solve the problem. I wanted a named asset, so I paid XCP for my assets. Spammers will get no sympathy from me but we’re talking about a protocol here. A Non- racist, sexist or elitist protocol.

Counterparty needs to implement a minting method like btc/src has, which is basically a free mint via a tx.

At issuance, a new asset could have a max supply or block height at which it locks. In the meantime, it’s open to anyone to issue more up to a limit.

It has .. until Monday

Don't understand. Like a dispenser contract that destroys the unsold supply at a pre determined time?

I was imagining an unlocked asset that allows issuance from any wallet.

For example, I issue asset XXXCP and choose to make it an open mint rather than a closed one like we have today.
Parameters could be set like they’re using: max mint supply; total supply. Additionally, a block height could be given to start/stop the open mint.

I believe this would be difficult to implement. Have you voiced the idea in the other chat? Maybe jdog or looney know better

I have, and Looney was interested.

I’m just spitballing, trying to come up with a proactive way to retain users while decreasing demand for the src method. It would take a bit of time to try to work in, but if the demand for such token mints maintains, it’s worth working on getting ready.

They aren’t really spam if they are valid transactions. The same defense xcp uses from btc devs against xcp, apply in reverse. You still gotta pay the corn fee. Junkmail pays postage too. I would advocate for no update on Monday and work towards a major version update instead. Without knowing how many nodes are running and on what version, stamping utilities could delay or deny updating and cause transactions that don’t validate, unless old cp tx’s would validate which then means there is no incentive to update your node. Protocols do not update constantly. Maybe some of these issues about database normalization, data duplication and tx formatting should be handled on the ui and ux level until a major protocol upgrade can be completed.

What do you think @krostue ?

i am still behind in the other chatrooms.
there are a few problems which are repeating themselves, and in some cases getting more intense each time. Jeremy controls the protocol and has demonstrated on multiple occasions that he has no intention to act on behalf of the community at large. Instead he is a profiteer which looks to exploit the good nature of the community with his position as primary service provider. He follows a few people who influence him to act in contradiction to what he has claimed.

If he is forking monday, then what can we do to preserve the current (broken) system? It should be declared publicly that Jeremy is continually working against the consensus of the community and his further degradation of the protocol will not be tolerated.

all in all the protocol needs a complete overhaul. the next hard fork should be a fully developed solution, not another bandage on a bandage. Lets get real. if he cant turn off Autocomplete for years and denies its existence for seven months, then can he be expected to be competent and responsible?

meanwhile it looks like it is up to the users to tell each other how to remove their previously stored private keys from the WEB DATA file.

I agree that spam is not the correct term. On a permissionless system people can do what they want. Most of we/I do is spam in most eyes too.

That said, i believe a protocol should be designed with incentives to promote certain behaviors.

In this case, make it cheaper to use broadcasts as this is healthier for nodes and the overall counterparty ecosystem. A fee on issuances should have been added long ago.

I haven’t.

Sounds like you have your own node, correct?

Is there a public discussion on the 0.25 fee on numerics? Another thing I don’t agree with is using an obscure forums platform instead of just relying on GitHub like most open source projects do!

Several indeed

Not possible in the current architecture. Only the issuer address can issue, one at a time. For another address to issue, you need to do an issuance transfer.

But something like that can be done on the opposite side, by destroys. Anyone can destroy an asset. But is not the same dynamic as you mention.

TLDR, not possible natively.

What version? And it seems you are issuing transactions from your own node right? You aware of…

This?

Yes, we did move to the ew 9.60 and receive different timestamps and transaction IDs for all stamps when re-indexing. But it was possibly because of bootstrap. Haven’t had a chance to verify

I assume this is based on prioritizing the “stamp index”. The stamp issuances (txid, block, time) should not have changed.

I’m not sure if I’m going to update my node. I can’t support the sloppiness of how updates are done. This was not supposed to be a protocol change, yet it was. And now it seems they are going forward with adding fees in a reactionary way without any open discussion about it.

But I won’t make a big deal about not upgrading, as I’m not currently making Counterparty transactions from my node. I’m at a point where I don’t care that much about the specifics of sub-protocols (Counterparty, Ordinals), what I care is about ART in Bitcoin.

This will become evident in the next release of bitSTART. Coming very soon! 🤓

But why?

😂😂😂😂😂

Had to screenshot this moment 🥹

Right click save ! Haha

21 dispenses on xcp.dev.
20 on xchain

I located the tx and raised an issue on github .. https://github.com/CounterpartyXCP/counterparty-lib/issues/1240

Is it possible to compare versions on github? The exact code changes.

Wow, great find @jp_janssen ! Even more reason to avoid the upgrade, the expectation is that it would have increased the allowed transactions, it did the opposite 😑

You can easily see all changes in one page here: https://github.com/CNTRPRTY/counterparty-lib/compare/master...CounterpartyXCP:counterparty-lib:master

Or here which compares it to its own repo (shows the same as the above link): https://github.com/CounterpartyXCP/counterparty-lib/compare/v9.60.1...v9.60.2

Do you know which line of code that caused the inconsistency?

When i looked at the actual btc txs, the same buyer bought from several dispensers with a chain of transactions, all confirmedin the same block. Nothing special.
v9.60.2 skipped the 4th dispense for some mystical reason.

I posted in the other chat that 9.60.2 is tracking a tx with a higher fee.

https://blockstream.info/tx/fb057107cff648877e8233b82f8a1791d763dd2cba321281e8d302e8a59e6290

This TX does not load in xcp.dev

True, then these are new transactions the updated node reads. So it is missing some but also detecting new.

It is definitely a consensus change, not a minor update.

No I haven’t studied the changes at the low level

🙌 welcome!

Btw that tx is the other end of the tx JP J mentioned. Not sure if that was evident.

Looks like a double spend (between versions)… right?

So is not like the old version sees it different in this second transaction, is just the dispense that was still left based on the new version missing it from the first transaction?

The first transaction was rebroadcast with a replace by higher fee. Your version is ignoring the higher fee tx. Are you also running a 9.60.2 server?

Nope

Still in 9.60.1

What’s odd is there’s nothing special at all about that dispense

It even uses a legacy address

do you guys have any thoughts on how to properly tweak this function? Appears to be the root of the insufficient funds error for sure. I'll spend some time on it in the morning, but wanted to put it out there for review.

https://github.com/CounterpartyXCP/counterparty-lib/issues/1242#issuecomment-1556259653

What do you mean when you say “In the way that this is removing items from the dict it appears to be assuming that all transaction inputs are spending previous outputs entirely, which may not always be the case.”

Are you referring to vout?

I was under the impression that Counterparty didn’t support RBF, maybe by design. Is this what the update did?

Quote jdog:
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

If the intention of the update was to allow transactions that previously errored out, then it was always going to be a consensus change. Not a minor update / bug fix.

reading through this and it doesn’t look like any of these changes has anything to do with block parsing/validation, its only the mempool parsing thats affected with the blocks.py change

Maybe, I haven’t studied the code. But I did read the PRs, and this one says:

“This would allow CP to generate the transaction without throwing a false BTC balance error.”

https://github.com/CounterpartyXCP/counterparty-lib/pull/1228#issuecomment-1473932135

that should just be tx creation via API, not parsing or validation

See other dev chat for updates

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 🎉️️️️️️

This makes the most sense, but also shows the risks of running via bootstrap

I removed all bootstrap code from my fednode/counterparty-lib code. Whatever backup I need I do it at the infrastructure level, not the protocol. I’ve always found it dumb that the protocol uses a bootstrap as a default

I'd love to stay up to date, but this user was banned from the other chat months ago for bringing up the autocomplete negligence

not too different than bitcoind defaulting to assumevalid

I disagree, the bitcoin node does download all block headers each time. Counterparty has no equivalent header per block at the main protocol it lives on, Bitcoin. It relies on going transaction per transaction always

there is a ledger hash per block

but it is different yes

counterparty could include ledger hashes at certain block heights when bootstrap is updated, like what bitcoin releases do with block hash

https://github.com/bitcoin/bitcoin/pull/25946/files

Another problem with the bootstrap is that it is a human created file. The protocol repo has no place where the bootstrap is created as far as I know.

The default RELIANCE on it is my problem. Well, not MY problem anymore because I run my own code 🤓

And let’s not forget v9.60 also had a very messy release in part because on the reliance on a centrally controlled bootstrap. Of the last 3 releases, 2 have had bootstrap related issues

The missing tx is now on xchain fwiw https://xchain.io/tx/16bd438b1dee6b1f750758eeabef7a876c204082a088c48ca51c416d6651d5db

🤔

Different ledger hash and message hash. Same block and tx list hash, I think.

They’re supposed to be all the same, but the website says is on maintenance so maybe it still in some sort of transition (not sure why / how only the txlist hash would match)

xchain skipped a whole load of blocks

yeah there is a banner now saying "This site is currently undergoing an upgrade and will be updated when the upgrade is completed. Thank you for your patience!"

I wonder how the oracled dispensers are doing in the face of these problems.

Easy to check: https://www.xcp.dev/address/1BTCUSDupRmeaNferCFoxmF6bYV5cAR2X2

The protocol is running just fine. I haven’t had to do any kind of upgrade to the node in all this time

Or the xcp.dev backend (aside from minor improvements because of the recent increase in exposure 🙏)

Hey Juan. Is there a way to show address holdings on bitstart? I can get it on xcpdev

790486 is the current block xchain has re parsed in the background .. it has around 600 blocks to go to close the gap it's 150 ish blocks on from the block shown in the image and has around 600 to go ... I expect it will be another 24 hours until its caught up

Bitstart is transitioning into only focusing on the art data, not the quantities/divisibility of issuances. At the moment some quantities wont be accurate (not updating destroys) and the next release will remove them entirely.

Xcp.dev will be the place for the complete asset info.

And thus xcpdev will also be the place for the complete data from an address

Radical! Thanks Juan

@jp_janssen just learned about that library. It should not be hard to make the op_return order modification if you make a fork specific for counterparty transactions. But I also see a lot of usefulness if you publish just the Counterparty messages code on its own

juan seems like there was some funkiness with the reorgs we had the last couple months that caused the message indexes to be off between your node, yours skipped message index 9156233 for some reason

https://www.xcp.dev/block/781277

Do you know what might have caused that? Gm

there was a reorg on that blcok

Yeah I realise that
But what caused the reorg?

https://twitter.com/BitMEXResearch/status/1637399783718436864?s=20

not everyone gets reorged during a reorg, only those nodes that follow the chain with the orphaned block

Thanks

Ill read up

It is my understanding that counterparty handles reorgs…

yes with the undo table

or it should

Yeah up to 100 blocks I think, which is kind of overkill lol

that would be a hell of a reorg lol

So are u saying its a privately made desciosn?

i think that happened in 2013, a multi day chain split

I'm finding it hard to understand sorry

What would actually cause it

Someone flipping a switch.. like in ghostbusters?

no the server itself keeps undo tables so it can rollback in case it ends up on an orphaned block

Yeah I have heard about that

But this wasn't an orphaned block though.

Interesting didn’t know that, but as you go earlier it would have been more possible. Nowadays it would require too much energy (PoW)

it was a bitcoin version update that caused the split

Can u even go to a school to learn this?? You guys.. blow my mind

class is in session stampy

Noted lol ❤️

Oh ok that was the hard fork that once happened

yes

accidental hard fork

About this, why the comment? We (xcpdev and xchain) were consistent up until a few days ago…

because the message index skipped a number

which is odd to say the least

just something i wanted you to be aware of

🤔

There is a transactions view in xcp.dev with all tx_index serial numbers: https://www.xcp.dev/transactions#2269150

Maybe also have a messages view with the message_index serial numbers would be interesting right?

sure

this is what i was referring to

from block 781277

there’s no 9156233

jdog is running a reparse on another server starting prior to the reorg so will see what his node says at that point

but i have a feeling the hashes wont line up correctly due to the message index being off by 1

Yeah I saw

Why? His node should just have the same skipped index

I finally got Bitcoin on St Patrick’s Day of 2013, and this fork happened basically right around then.

Right around then for me too. Class of 2013

Everyone seems to be lol

his node wont know there was a reorg

since its reparsing

https://www.xcp.dev/block/788837

here’s another one due to reorg

goes from 9441178 to 9441180

my guess is just a bug in counterparty-lib

off by 1

ooooh wait i see whats happening

the reorg itself is given a message index

https://www.xcp.dev/block/788838

9441179

interesting

My believe is that the protocol is already reorg proof. I think I’m going to do the messages view, it is educational

thats what i thought as well, im just double checking everything

https://www.xcp.dev/block/791307

On this block, I set up a dispenser to dispense at 1 sat - message index 9589958
I also transferred ownership to the dispenser address, which are the next 2 messages.
That involves a 546 sat transfer. Do dispensers dispense in the same block if indexed in the correct order?
Should that 546 sat transfer trigger the dispenser?

I don’t think dispensers set dispense in the same block, but I could be wrong

I always assumed it worked like the DEx, where you could try to time and front run transactions to beat out an open order being filled

https://mempool.space/tx/bf1a115d150e1505ddc34ce85d5fcf1cb97e25ff8f500b6df9e12fa3ed94928f

I'm testing out the asset ownership dispenser here

Xcpdev is not yet supporting dispenses / order specific views… is still mostly focused on the messages and asset/addresses in terms of issuances / broadcasts but not the “market”-type transactions. In part is on purpose as xchain already focused a lot on the market type data

The 546 sats sent with asset ownership does not trigger a dispenser.

Xcpdev is about the protocol data and consensus of this data. In an educational way. And with hashes front and center to be easily verifiable

Yeah that’s what I would have thought

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).  Temporary solution to be replaced with a dynamic fee later. 

What do you guys think?  Should i submit a CIP?

Interesting edge case. I believe it works as intended. If not a counterparty transaction, then check first output for dispense.

The invalid issuances to be ignored from the issuances table I don’t think is a trivial change, is deep into the architecture of the protocol

Then if invalid issuances cannot be ignored, than adding a fee does almost nothing in preventing the spam to the protocol SQLite DB

False logic becomes more valid when the goal of fee redirection is revealed

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/6431

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 the XCP dev redirection is not cool imo

What do you mean by redirection? Including any XCP fee?

Is not in @jp_janssen draft, but in the response from Jeremy

not clear on the subtext but i do agree nothing should be done in haste

Shifting point of authority across multiple tables? The answer you get depends on who is asked and when? Order of operations?

The flaw in your foundation become apparent as you build your roof.

This is badass!!! 🔥

Recycling xcp fees back to a dev address?

Sounds like it could be contentious, maybe it's needs to be a multisig community controlled address rather than a p2pkh .. with broadcasting voting ? ... but then we back to .. we reject: kings, presidents, and voting. We believe in: rough consensus and running code

@c0rnh0li0 v0.9 of xcp.dev was just released with this fix! Thanks for bringing it up

https://www.xcp.dev/asset/MEGACORN

Messages view is now available in https://www.xcp.dev/messages

Its sub asset also helped me get to the bug. Fckn cool man! 🔥🔥🔥

https://www.xcp.dev/asset/A3394922408985419114

Oh no! You fixed my bugged token!? 😅

I’m happy to have been of some help.

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.

Lol the protocol should be fine, were you able to do something related to that bug? The problem was in the presentation of the data, not the data itself

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.

juan can you send me the api results data for get_messages on block 785271

thats where the ledger and messages hashes diverge from your node and xchain

trying to figure out why

i thought it was related to the reorgs and message index but its not

Request: https://97bhdwc2g0.execute-api.us-east-1.amazonaws.com/block/785271

Response: {"ip":"","message":"","data":{"block_row":{"block_index":785271,"block_hash":"0000000000000000000151c70556b3309fe6253cc23938381935cc252911a91c","block_time":1681422208,"previous_block_hash":"000000000000000000006458dbc55623b2f166544bb7bf5b7f3f71c8e9a8c979","difficulty":47887764338536.25,"ledger_hash":"51abb403cfdd21de771892134bee6f254b6350dc46bc6c2ead3df8500827ef2f","txlist_hash":"944f958d62e2f9435c2ef4f82f3e0160f7b20e2d995cada3f72ad4c217837c15","messages_hash":"d5fda73567d8d8489e5d5a779a66196442e0f1324e42ea3ae886cd6c41d98651"},"messages":[{"message_index":9344113,"block_index":785271,"command":"insert","category":"debits","bindings":"{\"action\": \"send\", \"address\": \"12RNRyf6T2Kf8TsS6BpQ7AKniTQuCBH3fZ\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"2e905ca45e3ec9281410456c3d51d9a65a6a8d8ef3607058c1efe3b4f6e174d3\", \"quantity\": 500000000}","timestamp":1681422279},{"message_index":9344114,"block_index":785271,"command":"insert","category":"credits","bindings":"{\"action\": \"send\", \"address\": \"bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvx3jg6pu\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"2e905ca45e3ec9281410456c3d51d9a65a6a8d8ef3607058c1efe3b4f6e174d3\", \"quantity\": 500000000}","timestamp":1681422279},{"message_index":9344115,"block_index":785271,"command":"insert","category":"sends","bindings":"{\"asset\": \"XCP\", \"block_index\": 785271, \"destination\": \"bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvx3jg6pu\", \"memo\": null, \"quantity\": 500000000, \"source\": \"12RNRyf6T2Kf8TsS6BpQ7AKniTQuCBH3fZ\", \"status\": \"valid\", \"tx_hash\": \"2e905ca45e3ec9281410456c3d51d9a65a6a8d8ef3607058c1efe3b4f6e174d3\", \"tx_index\": 2318947}","timestamp":1681422279},{"message_index":9344116,"block_index":785271,"command":"insert","category":"debits","bindings":"{\"action\": \"issuance fee\", \"address\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"3074637597324765a03e4362f3510eda3530a5ddc2270bfa512764b97dda22ec\", \"quantity\": 0}","timestamp":1681422279},{"message_index":9344117,"block_index":785271,"command":"insert","category":"issuances","bindings":"{\"asset\": \"A1255196356911407600\", \"asset_longname\": null, \"block_index\": 785271, \"call_date\": 0, \"call_price\": 0.0, \"callable\": false, \"description\": \"STAMP:R0lGODdhBgAHAPAAAAAAACDDDiwAAAAABgAHAAACC4QPoWGMrJpMC50CADs=\", \"divisible\": false, \"fee_paid\": 0, \"issuer\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"locked\": true, \"quantity\": 0, \"reset\": false, \"source\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"status\": \"valid\", \"transfer\": false, \"tx_hash\": \"3074637597324765a03e4362f3510eda3530a5ddc2270bfa512764b97dda22ec\", \"tx_index\": 2318948}","timestamp":1681422279},{"message_index":9344118,"block_index":785271,"command":"insert","category":"debits","bindings":"{\"action\": \"issuance fee\", \"address\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"be8d75d28a91b2c694c79b9111bb0fc5180ee80eea0b6d8ef1bbb120753e055a\", \"quantity\": 0}","timestamp":1681422279},{"message_index":9344119,"block_index":785271,"command":"insert","category":"issuances","bindings":"{\"asset\": \"A1280690063939660000\", \"asset_longname\": null, \"block_index\": 785271, \"call_date\": 0, \"call_price\": 0.

0, \"callable\": false, \"description\": \"STAMP:R0lGODdhBgAHAPAAAAEBASDCDywAAAAABgAHAAACCoRvEbfQn2JqyBQAOw==\", \"divisible\": false, \"fee_paid\": 0, \"issuer\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"locked\": true, \"quantity\": 0, \"reset\": false, \"source\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"status\": \"valid\", \"transfer\": false, \"tx_hash\": \"be8d75d28a91b2c694c79b9111bb0fc5180ee80eea0b6d8ef1bbb120753e055a\", \"tx_index\": 2318949}","timestamp":1681422279},{"message_index":9344120,"block_index":785271,"command":"insert","category":"debits","bindings":"{\"action\": \"issuance fee\", \"address\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"dc6b85c281ab0aac83a55ace185d03828fee96193b58cc011457c050312a1c65\", \"quantity\": 0}","timestamp":1681422279},{"message_index":9344121,"block_index":785271,"command":"insert","category":"issuances","bindings":"{\"asset\": \"A1569314151460095000\", \"asset_longname\": null, \"block_index\": 785271, \"call_date\": 0, \"call_price\": 0.0, \"callable\": false, \"description\": \"STAMP:R0lGODdhBgAHAPAAAAAAACDCDiwAAAAABgAHAAACCoQPoWGMe1yEyBQAOw==\", \"divisible\": false, \"fee_paid\": 0, \"issuer\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"locked\": true, \"quantity\": 0, \"reset\": false, \"source\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"status\": \"valid\", \"transfer\": false, \"tx_hash\": \"dc6b85c281ab0aac83a55ace185d03828fee96193b58cc011457c050312a1c65\", \"tx_index\": 2318950}","timestamp":1681422279},{"message_index":9344122,"block_index":785271,"command":"insert","category":"debits","bindings":"{\"action\": \"issuance fee\", \"address\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"44dec58bbfe78e76d51bd034a6ef291169d125d0018089c3e316da25170d20c3\", \"quantity\": 0}","timestamp":1681422279},{"message_index":9344123,"block_index":785271,"command":"insert","category":"issuances","bindings":"{\"asset\": \"A1941461611175787500\", \"asset_longname\": null, \"block_index\": 785271, \"call_date\": 0, \"call_price\": 0.0, \"callable\": false, \"description\": \"STAMP:R0lGODdhBgAHAPAAAAAAACHCDiwAAAAABgAHAAACC4QPoRfW6SJMC50CADs=\", \"divisible\": false, \"fee_paid\": 0, \"issuer\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"locked\": true, \"quantity\": 0, \"reset\": false, \"source\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"status\": \"valid\", \"transfer\": false, \"tx_hash\": \"44dec58bbfe78e76d51bd034a6ef291169d125d0018089c3e316da25170d20c3\", \"tx_index\": 2318951}","timestamp":1681422279},{"message_index":9344124,"block_index":785271,"command":"insert","category":"debits","bindings":"{\"action\": \"issuance fee\", \"address\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"c742819dc7a613700d01a0596665ce3999282b7dd1678b70a6abd47a5b2cc676\", \"quantity\": 0}","timestamp":1681422279},{"message_index":9344125,"block_index":785271,"command":"insert","category":"issuances","bindings":"{\"asset\": \"A2714923420641146900\", \"asset_longname\": null, \"block_index\": 785271, \"call_date\": 0, \"call_price\": 0.

0, \"callable\": false, \"description\": \"STAMP:R0lGODdhBgAHAPAAAAEBACDCDiwAAAAABgAHAAACCoQPoXGK3pBh0hQAOw==\", \"divisible\": false, \"fee_paid\": 0, \"issuer\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"locked\": true, \"quantity\": 0, \"reset\": false, \"source\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"status\": \"valid\", \"transfer\": false, \"tx_hash\": \"c742819dc7a613700d01a0596665ce3999282b7dd1678b70a6abd47a5b2cc676\", \"tx_index\": 2318952}","timestamp":1681422279},{"message_index":9344126,"block_index":785271,"command":"insert","category":"debits","bindings":"{\"action\": \"issuance fee\", \"address\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"90d3a614cfb6dfece28ba9d4d72cc59bb5c4d41594516bf62cb5c04bf0af589f\", \"quantity\": 0}","timestamp":1681422279},{"message_index":9344127,"block_index":785271,"command":"insert","category":"issuances","bindings":"{\"asset\": \"A2744077093864902700\", \"asset_longname\": null, \"block_index\": 785271, \"call_date\": 0, \"call_price\": 0.0, \"callable\": false, \"description\": \"STAMP:R0lGODdhBgAHAPAAAAAAACDDDiwAAAAABgAHAAACC4QPYZq7AV2bDIECADs=\", \"divisible\": false, \"fee_paid\": 0, \"issuer\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"locked\": true, \"quantity\": 0, \"reset\": false, \"source\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"status\": \"valid\", \"transfer\": false, \"tx_hash\": \"90d3a614cfb6dfece28ba9d4d72cc59bb5c4d41594516bf62cb5c04bf0af589f\", \"tx_index\": 2318953}","timestamp":1681422279},{"message_index":9344128,"block_index":785271,"command":"insert","category":"debits","bindings":"{\"action\": \"issuance fee\", \"address\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"d7714898394d5cba675fb419c5d101e4af8d17327dea082f56d408bfc3d388b0\", \"quantity\": 0}","timestamp":1681422279},{"message_index":9344129,"block_index":785271,"command":"insert","category":"issuances","bindings":"{\"asset\": \"A277926019791383550\", \"asset_longname\": null, \"block_index\": 785271, \"call_date\": 0, \"call_price\": 0.0, \"callable\": false, \"description\": \"STAMP:R0lGODdhBgAHAPAAAAEBACDDDiwAAAAABgAHAAACCoQPoWGM646D6BQAOw==\", \"divisible\": false, \"fee_paid\": 0, \"issuer\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"locked\": true, \"quantity\": 0, \"reset\": false, \"source\": \"1EWFR9dMzM2JtrXeqwVCY1LW6KMZ1iRhJ5\", \"status\": \"valid\", \"transfer\": false, \"tx_hash\": \"d7714898394d5cba675fb419c5d101e4af8d17327dea082f56d408bfc3d388b0\", \"tx_index\": 2318954}","timestamp":1681422279},{"message_index":9344130,"block_index":785271,"command":"insert","category":"debits","bindings":"{\"action\": \"open order\", \"address\": \"1L3qaF8ebnBKEvQTXTDnmdUxDhExSsdWjm\", \"asset\": \"OXRAREPEPE\", \"block_index\": 785271, \"event\": \"8dfcdee6fbe4ecf23e7a7fe318913305fd3c35e8a5964464e524277e97d9a7c2\", \"quantity\": 1}","timestamp":1681422279},{"message_index":9344131,"block_index":785271,"command":"insert","category":"orders","bindings":"{\"block_index\": 785271, \"expiration\": 8064, \"expire_index\": 793335, \"fee_provided\": 1855, \"fee_provided_remaining\": 1855, \"fee_required\": 0, \"fee_required_remaining\": 0, \"get_asset\": \"RAREPEPE\", \"get_quantity\": 1, \"get_remaining\": 1, \"give_asset\": \"OXRAREPEPE\", \"give_quantity\": 1, \"give_remaining\": 1, \"source\": \"1L3qaF8ebnBKEvQTXTDnmdUxDhExSsdWjm\", \"status\": \"open\", \"tx_hash\": \"8dfcdee6fbe4ecf23e7a7fe318913305fd3c35e8a5964464e524277e97d9a7c2\", \"tx_index\": 2318955}","timestamp":1681422279}]}}

thanks!

What is the issuance message issue?

You know

there is a checksum issue with a receive address in block 785271

2e905ca45e3ec9281410456c3d51d9a65a6a8d8ef3607058c1efe3b4f6e174d3

you have destination address on that send as bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvx3jg6pu

but thats an invalid checksum

bitcoin-cli validateaddress "bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvx3jg6pu"
{
"isvalid": false,
"error_locations": [
],
"error": "Version 1+ witness address must use Bech32m checksum"
}

when i look at your reparsed message data

it’s correct

{
"bindings": "{\"action\": \"send\", \"address\": \"bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvxywcky7\", \"asset\": \"XCP\", \"block_index\": 785271, \"event\": \"2e905ca45e3ec9281410456c3d51d9a65a6a8d8ef3607058c1efe3b4f6e174d3\", \"quantity\": 500000000}",
"block_index": 785271,
"category": "credits",
"command": "insert"
},
{
"bindings": "{\"asset\": \"XCP\", \"block_index\": 785271, \"destination\": \"bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvxywcky7\", \"memo\": null, \"quantity\": 500000000, \"source\": \"12RNRyf6T2Kf8TsS6BpQ7AKniTQuCBH3fZ\", \"status\": \"valid\", \"tx_hash\": \"2e905ca45e3ec9281410456c3d51d9a65a6a8d8ef3607058c1efe3b4f6e174d3\", \"tx_index\": 2318947}",
"block_index": 785271,
"category": "sends",
"command": "insert"
},

bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvxywcky7 is a valid checksum

bitcoin-cli validateaddress "bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvxywcky7"
{
"isvalid": true,
"address": "bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvxywcky7",
"scriptPubKey": "5114840698aad78a5c1ef68d50c8931ba6db02f0fd86",
"iswitness": true,
"witness_version": 1,
"witness_program": "840698aad78a5c1ef68d50c8931ba6db02f0fd86"
}

so it appears that your reparsed node is correct

but why did it create a bad checksum at some point for both yours and juans nodes

i dont know

this is what i just sent to jdog

Different destination addresses for the same cp transaction? As in the same txid?

Yes but look at the two addresses

Checksum is calculated by Counterparty-lib

So the 21 bytes specified in the address field is the same for both addresses and one of them just has an invalid checksum

I see the same destination address in both:

- https://www.xcp.dev/tx/2e905ca45e3ec9281410456c3d51d9a65a6a8d8ef3607058c1efe3b4f6e174d3
- https://xchain.io/tx/2e905ca45e3ec9281410456c3d51d9a65a6a8d8ef3607058c1efe3b4f6e174d3

This

bitcoin-cli validateaddress "bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvx3jg6pu"
{
"isvalid": false,
"error_locations": [
],
"error": "Version 1+ witness address must use Bech32m checksum"
}

That address has an invalid checksum

bc1pssrf32kh3fwpaa5d2ryfxxaxmvp0plvx3jg6pu looks like an address Javier sent XCP to

Interesting, it’s also bc1p and not bc1q

I wonder if bitcoinlib needed an update to parse that properly

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

I think I understand, the script pubkey (hex) is stored in the tx data so counterparty has to re create base58 encoded address which includes a checksum and something caused it to do that incorrectly ?

yep im looking at it right now actually

i decoded the message data in that tx

this is the address hex data 81840698aad78a5c1ef68d50c8931ba6db02f0fd86

notice that initial byte

bech32 uses the 80 byte

p2pkh is 00

and p2sh is 05

What asset is this about?

so from BIP-350 it appears that shorter bc1p addresses are actually valid https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki

it was the first keyburn bitcoin stamp that resulted in a invalid tx

https://xchain.io/asset/A2222222222222222222#issuances

https://xchain.io/tx/2317041

A808022222222222222 ended up being the first keyburn bitcoin stamp

SPENDME was the first keyburn asset

the github issue regarding the api generating an invalid transaction is

https://github.com/CounterpartyXCP/counterparty-lib/issues/1245

Got it the problem is in the api, the protocol is still correctly considering these invalid

https://www.xcp.dev/asset/A2222222222222222222

yes .. was trying to match asset id with the keyburn pubkey 022222222 .. thats why .. was api issue

I not yet skilled enough to manually make a raw cp tx yet .. I just playing with api for issuance as it allowed me to develop the keyburn idea for utxo permenace

I made an invalid tx this past week: https://www.xcp.dev/tx/30ac747b3fc260b291278fef365d982e1c1b1562b88893351ba0a827a216ce88

Are you going to be doing more issuances with stamp-like “STUNK:…” descriptions? I can add support for these in bitstart…

No, it was just a joke issuance stamp. Thanks

What tool did you create the tx with?

😆 now I want to do it even more out of curiosity lol

I’ll check that one individually then… but if is cool I will support it 🤓

I simply did 2 transactions on 2 steerage wallets where I pumped up the fees for the 2nd one so the one with the base64 would be the invalid one.

It’s a hidden, fake logo

ah right .. so you can make two transactions using the api and not broadcast, then sign and broadcast them both which then cause one to becomes invalid due to the other being mined first, you cant sanity check that type of behaviour