Houston... we have a problem

I was hoping it was just isolated to testnet... but seems to be on mainnet as well

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

not sure when this change got implemented... or how no one noticed.... but now that tx fees are insane, this is a bit more noticeable... paying a high tx fee and then seeing the outputs that are supposed to be using 546 dust using the fee amount

please verify my findings... and we should get this fixed in the next release... luckily this is limited to p2sh encoding which is only used in MPMA so far... so impact is minimized

but still should get dat shit fix0red asap 🙂

Please, try with another fee, different from 1000

Just to confirm something

sure thing... trying with fee 123456

confirmed

fee is 123456... p2sh encoded output amount is 123456

At least we now warn in freewallet (currrent version that is already release and in use) about the data encoding fees.... so anyone trying to do MPMA sends is seeing the accurate fees for the data encoding and will NOT be doing an uninformed MPMA send that will cost them hundreds of dollars

Full disclosure ASAP... 20 mins after I discovered.... Please be careful if your doing MPMA sends in this high fee environment... it could result in some insane data encoding costs.

is this what happened in this txn? https://mempool.space/tx/05bb596a7a4e6dfe7e6853f223fa018af2af4d87da30a501a41db97d32980386

I that happened for this MPMA https://xchain.io/tx/2320795 where some 2nd txn came out using a much lower fee

https://mempool.space/address/3KVtqQr2K39bx8aaSeaEZc8UeMcVRHs2wW

1DMCrvh4NbkToZi9xmssQoEaFcNk33CC51 being the originating txn sending address

i dunno if that helps but something wierd occured when i was loading physicals for NFT NYC. Seems like it could be related to or an example of it occuring..

No... MPMA is 2 part transactions... you referenced the second tx... but if you look at the first tx, that is where all the data is encoded.. and that tx is https://blockstream.info/tx/7bc70fe9d90dfb298395e9dc378166c04abc6b08c5f45bd2882f472586595357 .... and it uses 546 outputs

looks like the same tx fee was used on both first and second tx (2385 sats)... but it do see an output that is not 546 dust... so maybe

Javier is digging into this issue now to confirm it... the issue I created is for behavior I observed on the first output.... in your case, it looks like the first output used the expected 546, then the second output used some funky dust amount, then the 3rd output is your change

so yeah... this tx DOES appear to be a lil funky on first glance... not the exact issue I described, but still not the expected behavior

okay, glad I shared then 🙂 - thanks guys

FYI..... my above alarm about an issue with p2sh dust outputs was misguided..... Turns out those outputs are used to pay the tx fee on the second tx... and the final data output value is adjusted to whatever value we need to make up the desired miners fee on the second tx. All is well... sorry for any confusion :)

Blockchain.com is recognizing a named asset as an A asset.. I’m guessing this is from the CP api not on the xchain api?

This is asset soccergoal

cant' speak for how some other website displays stuff

both CP API and XChain API pass asset name correctly

Interesting

This is another case of someone minting a subasset stamp... which happens to be on a numeric... then calling it a "Bitcoin Stamp"... which it is not... YEs, the stamp technically lives on a numeric, but it is a subasset, so "Bitcoin Stamps" doesn't consider it a "stamp"

No this is a named stamp

SOCCERGOAL

ahh... got ya... yeah...

https://xchain.io/tx/7f9fbd58002632d422005fbd3391d292d0b65a63818c17286724a0573f110d3e

looks like it is a named asset... would have to ask blockchain.com why they show stuff funky... like you have to ask rarestamps.xyz why they dont support all stamps, and ignore named bitcoin stamps 🙂

Blockchain.com just making shit up lol

ah... I get what they are doing

every named asset is translated into a numeric name.... and that numeric name is what is passed inside of counterparty messages... we say "pass A100671381986563" which translates to SOCCERGOAL when decoded..... blockchain.com is just decoding the raw counterparty message, and showing the encoded numeric asset id.... which is NOT the actual asset name used in Counterparty

Yeah they built this entirely independently. We don’t even know anyone who works there

I’ll reach out see if it can be fixed

They should be pulling asset names from counterparty, or xchain.... reading the raw asset data is no bueno... doesn't indicate state... what if this asset didn't have enough XCP to pay the minting fee... would be a bitcoin tx, but not a valid CP tx... but blockchain.com would still show it as a valid registered asset

state matters 😛

Matters of State, one might also say :)

if you find a blockchain.com dev contact, pls invite them here 🙂

I think i know them

i have invited to chat

https://www.rarestamp.xyz?fresh=true

good people

believe spanish is primary language

Hello

Thanks bench

We dont support other protocol for stamps at the moment we Will do in the future we want to have everything working well with Bitcoin Stamps but Will be all other BTC and DOGE stamps in a future. Rarestamp

sup brc20 lovers! 😂

who controls the xcp twitter?

All cp properties are controlled by moi…. GitHub, Websites, wallets, explorers, Twitter, Reddit, etc etc…. What do ya need? A retweet or something?

good news: say hello to p2wsh in CP. This tx stores all protocol data for a send in the witness. Still have a mess in the code and have to write a CIP for this,..... and have to test it very VERY well, but it's already a reality

sick, good work

Ok, noted. I need nothing. Was going to suggest a tweet thread response to what's going on.

if you want tweetdeck access to tweet and retweet stuff as CounterpartyXCP... pls DM me.... your a long-time and well respected community member... I know you'd use the access responsibly and not tweet anything that isn't in the ethos of CP 🙂

We have no community manager currently (last one quit, and we dont have funds right now anyway)... so, the engagement from CounterpartyXCP could be good and net benefit for everyone 🙂

i'm too busy to tweet from the account much, and its not really my thing, so I welcome the help

@pataegrillo thank you & @jdogresorg for getting Trezor support to work in the latest FW update! Amazing work guys!

Anyone got a tool to dump a bunch of pks for a given xcp 12 words seed?

Fyi…. Javier working on a mempool fix on Monday so ppl can start seeing pending cp txs again…. Not being able to see pending txs is causing some issues with dispensers n not knowing if payments are incoming…. Will get fix in place next week…. No new release yet, but can at least get xchain n api servers showing mempool updates (can run update/fix before release to solve immediate issue)

https://github.com/Jpja/XCP-Export-Segwit

Ah amazing!!!!!

This is going to save me sooooo much time!

cc: @jdogresorg @hodlencoinfield

I know that I asked this before, I think but my brain is slow and could not find searching. A collector in a rush googled freewallet downloaded the wrong one and provided the native BTC address to receive their 1st xcp token. Is it as easy as importing the private key into Freewallet and sending it out of that wallet?

This is the wallet so I think it is that easy but do not want to provide bad info

https://xchain.io/address/35FYC8Q1jGLVTpcNGh4AqnXVWBBygmSVmR

will create a video at some point as I think this happens more often that we think

That sucks…. Yeah, freewallet.org wallets are custodial…. So gotta reach out to them to get to send back or send u private key… once u have private key, yes, you can import into freewallet.io n use normally

Thought about rebranding a few times but love the freewallet name, so waiting out the other wallet… also reached out to them before using the name n they were fine with it…. Tho prolly not so much now that we didn’t just “go away” like they prolly expected😜

How would they be able to send it out? I have told them to request priv key but if they will not wondering if they can send

I’ve never heard of any custodial wallet service ever doing this.

They would have to use a CP wallet, import and send themselves

ya same I do not think they will and cannot imagine they will create a CP wallet and send out either

You gotta explain mistake n email n hope they send u back ur tokens…. Haven’t heard any successes on that front yet…. Maybe if a rare pepe or some really high value card was sent, they might pay attention… but most likely just lost forever

https://twitter.com/News_Of_Alpha/status/1655678808500969479?t=tJKftIwS5_HkmZDDbxJOxA&s=19

Now maybe they can re-add XCP on Global? 👀

Perhaps the XCP bag they hold can get liquidated finally and become available for use

Yup, or this

We need to ask Justin Sun for the other bag ^^

Why do we need it for use though, XCP is available to people who want it now

if a large portion of the supply is locked up, would prefer to get that liquid again... YES, it being more scarce will drive price up... but, I dont really care about price, more about keeping xcp flowing and available to those who want it, having this bag back in circulation would be a win IMO

FYI... Javier dug into this today and discovered that once BTC mempool gets over 50K pending txs, CP mempool stops updating entirely.... THAT is an easy fix (worst case, will try to update every 60 seconds at minimum)... but he also found a few other funky items in the way we handle mempool... CP mempool update was effectively dying whenever we failed to get a single tx via getrawtransaction_batch .... which was a bunch.... so, he is working on some fixes and optimizations, and once they are ready (Wednesday probably), I'll patch the production API servers, so that mempool will start returning relatively sane results again 🙂

if all goes well, will roll the PR into next release

@jdogresorg running into a weird issue... I'm on latest Freewallet. Trying to send an asset here: bc1q20d2cdvy2x83h3ssrz5lgryy4c9wqxsgc749ej

When I check transaction, I only see 1 output that goes here: 1FWDonkMbC6hL64JiysuggHnUAw2CKWszs (which I assume is the donation address)

Here is the transaction: https://mempool.space/tx/acf7bb7449a8ade61e6af3a84888f123c4b852524ca0ab736f591459f1396277

I just turned off donation in Freewallet and resent to the bc1q address and get this: https://mempool.space/tx/26abe4f36cd2b995e676fb8d059edf5e81bd3639f3eeef75bdebd37bfad81572

The output address is just the input address. No sign of the bc1q address

the address is part of the message

FWDonk lol

I imagine FWDon = Free Wallet Donation

@hodlencoinfield is it just me or is it really fucking hard to get a ledger to work with a web3 site? I tried it with yours and also Hiro wallet and can’t seem to successfully pair the Ledger. Tried every browser imaginable too. Latest firmware. Newest model Ledger.

It gets stuck at pulling addresses from the ledger

are you using chrome?

Chrome, chromium, brave, opera…

Everything I tried

and it works with ledger live?

Everything works up until the point where it attempts to retrieve addresses from the device

Then it’s just blank screen

Having the maximum amount of XCP in circulation for liquidity is the optimal outcome IMHO

does ledger live give you addresses?

Not by the computer at the moment… I was doing whatever it told me to do… I just bought the ledger so I don’t know ledger live that well

well if its not working on ledger live then im not surprised its not working anywhere else

i would try to update firmware

that might be your issue

Ok will try again

I kinda hate the ledger interface. Much prefer Trezor

you havent even used it yet lol

you just dont like the shape?

And I already hate it!

lol

i have both and i actually prefer the ledger now

I’ve only ever used Trezor so just muscle memory I guess

trezor you mean

Yeah

have you used trezor with eth?

Just in terms of receiving /sending ETH nothing fancy like tokens

ledger is much better and just better supported in general in eth land

and since i built a bitcoin ledger wallet i’ve used it a ton now for bitcoin too, i think you’ll like it once you get it working

okay now it suddenly works. I think I was using a chrome derivitive before on rpw now I'm using real chrome

So I'm kind of debating if I should move my pepes to Trezor given that Freewallet integrates Trezor or Ledger...

oh wait freewallet does do ledger

ahh no "The feature you are trying to access will be coming soon."

😞

Is there any way in the Counterparty api to just create message data without a transaction?

https://twitter.com/ordinalswallet/status/1655817080061526018?t=3GIdbyiBy271WM2VczZByg&s=19

Will this affect CP in any way?

Not if it’s focused on segwit data

if you find out ether way please can you let me know as im interested int he same question

@pataegrillo do you think this is something we could add to API if it’s not already accessible?

You know, i thought of that months ago. It's something totally feasible

But, there only one little detail...

In two txs messages, like when you use p2sh or p2wsh, there are two data messages. So, if the message is too long, probably the signaling message would be needed

you could but what im saying is just return the message itself no matter how long would help a ton for alternate implementations of tx creation

dont arc4 encode or anything

just give the hex string 434e545250525459….

that way it would be way easier to test against what the API produces

how about returning the hex and or arc4 encoded data

Well, that's simple, it could be done

Why was arc4 introduced in the first place? Early counterparty didn't use it.

wondering if this is just a "me" issue, or an actual bug that prevents sending assets in latest freewallet. I imagine it likely hasn't seen widespread reporting because no one has been able to send anything in the last few days.

I see no issue.... as Joe said, the destination address is encoded in the OP_RETURN

if you turn off auto-donate system, tx only contains OP_RETURN and your change output

if you have auto-donate system on, tx contains OP_RETURN, 1 donation output to 1FWDon..., and the change address

So far your the only one that has reported any issues... not saying that there isn't an issue, but haven't heard of it yet.... only other issue i've heard of since release was with sending to a segwit bc1 address... and that is cuz they were using mobile, not desktop

For now, I would suggest turning off auto-donate... cuz, high fee environment, and the extra output DOES increase the size of the tx a bit over standard send

🙂

not having visibility into CP mempool is frustrating... should be able to see the pending txs tomorrow... so if your tx isn't mined by then, at least you'll be able to see on xchain.io and see the send is normal, just "Stuck in the mempool with you..... feeeess.... feeees" 🙂

https://xchain.io/tx/3ddcf09985cf3b7d362a5f028c2bb6d4d1e6f2f653db1c74cfd000ec1e37c06a

https://blockchair.com/bitcoin/transaction/3ddcf09985cf3b7d362a5f028c2bb6d4d1e6f2f653db1c74cfd000ec1e37c06a

There is a CP send done via new version of freewallet... confirmed 3 hours ago... can see it is a normal send, and can see that it contains an auto-donation output to 1FWDon... so I THINK everything is working fine with sends, it was in testing.... if you find that is not the case, please let me know 🙂

What wallets do you guys use for testnet on BTC, normally I would not bother but with fees so high think it is a better play

block.io was found via google

you can use freewallet on testnet

I thought so

change your network settings

but was not sure

what faucet do you guys use

to get test coins

yh its cheaper to make stooopid mistakes there

lol

gimme testnet addy i can send you some

cool sec

gimme your address n i'll send you some

ok jdog has the bigger peen

lol

you can also burn BTC for XCP on testnet... if your looking to get XCP to test with

mxV4ZZ9uh3f1kcx1uPdzRCzRhdtAtuabM7

i think you gave me my testnet coins too actually

post your address too bro... send ya some of muh tBTC viagra 😛

nah this is just simple payment pooling

you already sent me some testnet coins

was looking at lighting and but that is for another deadline

https://blockstream.info/testnet/tx/8b896980594bcc42fc576c745d2836d4bd9406f5440653354ecd54752b73fcc9

"ⓘ overpaying by 36058%"

Recipient isn’t bc1

ya... freewallet doesn't use testnet fee estimates... uses mainnet.. so... overpaying a bit :P

ahh got ya now... specific send to segwit address... sec i'll dig through the donation address to see if I can find a segwit send

blockstream.info and mempool.space down.... guess we know what backend they use 😛

seems up for me

maybe a glitch

yep... mempool.space back up for me now too

but ya lots of things are breaking for me today

github even

To obfuscate data during opreturn wars

oh? what part broke? I saw your tweet earlier but didn't grok what specifically broke... co-pilot?

We don’t arc4 encode with p2sh encoding

So if you look at the input script sig of the 2nd half of a p2sh encoded Tx you’ll see the Counterparty message data

I’m working on adding testnet to rpw right now

Should’ve done this years ago lol

I’ve probly spent over a bitcoin in fees just testing wallets over the years

CP Send to segwit address
https://xchain.io/tx/64088f3cdaff44bdaf26ca7f6dfcfe0b8a33a469ae954053bf1dff6304f0dc9b

OP_RETURN, donate output, change
https://blockstream.info/tx/64088f3cdaff44bdaf26ca7f6dfcfe0b8a33a469ae954053bf1dff6304f0dc9b

@mikeinspace ^^ 🙂

seems like CP sends to segwit with auto-donate on are working ok.

Ok I guess I’ll let you know in a week when it confirms

I'm having an issue as well - @jdogresorg i just sent you screenshots in dm

Ooof

not great

looks like your issue is with broadcasting... so a bit different and prolly related to your specific address and UTXO setup... will answer your DMs 🙂

freewallet is hanging trying to send some btc on testnet, just stuck on Genrating cp trans

is this realted to blockstream having issues?

or my setup do you think?

might be the auto donate feature

tried to send btc and it didn't worked

then it worked when I disabled it

I have not updated to latest build yet

Yeah… should be hardcoded address for testnet… feel free to turn off when using testnet if it’s causing issues…. Will dig into it in a bit… but so far only issue is n testnet yes?

just installed lasted build, still cannot send on testnet same behaviour just hands

hangs

but did the same on version just before the ADS

was able to send via browsers version

hrm... hangs on generating transaction, signing, or broadcasting? anything helpful in the debug console?

need to figure out better fee estimation for mpma send

it uses same fee for both txs rather than same sat/vb rate

need better fee esimate in freewallet period

so multisends which should be a big help in high fee times are actually not very useful

yeah but doesnt counterparty api do that for fw?

it is ALL based off a set/standard send size... which is smaller or larger than the actual tx in many cases

will replace with a slider and pre-flight check the tx, determine size, and correct fee to use... prolly next release or two

what we could do is set a ratio for MPMA 2nd tx

its on my todo list... cuz yeah... fee esimation in freewallet is very rudimentary... suprised it works for most... lucky btc network is not demanding high fees most of the time 😛

based on the standard size fee

yeah i just started looking into this BRC thing and it might drag on for a bit, their UI is like opensea but for a shitcoin

I pass a hardcoded fee to the CP API... what I should do is just not pass a fee, do pre-flight check to generate TX (just to get tx size), then can more accurately calculate fees cuz we have actual size of tx.... then the fee slider X sats per byte thing is easy to implement... then pass the fee on to CP API from freewallet like I do now, but will have better estimated fee

This is just doing a send, I did not see anything in debug console

do you pass the fee for both txs separately when p2sh encoding is used?

yes... have to sign/broadcast the first p2sh tx before you can generate the second tx.... need the tx_hash from first tx for`p2sh_pretx_txid` param in the second tx

second p2sh call is EXACTLY the same as first except I give p2sh_pretx_txid

also... fee for second tx is determined in the first tx.... since all the outputs in the first tx add up to cover the tx fee on the second tx

COULD use different fees on the different txs I spose... but, not setup that way right now... but not that tough of a tweak if you wanted to play around with the codebase 🙂

Seems to be an SSL error on api.counterparty.io

https://api.counterparty.io/

port 14000 is HTTP ... port 14001 is HTTPS

this works for me 🙂

yeah... chain.so fails to broadcast testnet txs for some reason

https://github.com/jdogresorg/freewallet-desktop/issues/45

hope to work on this in an upcoming release... reduce my support load from the broadcast failure blackhole

https://live.blockcypher.com/btc/pushtx/

can copy / paste signed tx from console and broadcast to testnet there... (make sure you select Bitcoin Testnet as Network"

should give you a broadcast success or a more meaningful error message

worked

yup... will dig into why xchain testnet fails to broadcast when I have some time 🙂

no worrries not stopping me at all

fw mobile works fine

yea so it would need to be a parameter in the API itself when creating the first tx

since its added to the last p2sh output

so you could have a parameter when creating the pretx that says “second_tx_fee” or something and specify it that way

even better just pass an array into the fee parameter that’s only valid when creating the pretx of an mpma

you shouldnt even need to put a fee in for the 2nd tx because by default its using the entire value of the inputs as fee

yeah... but gotta pass a fee for the second tx to determine the dust value to put in the outputs... to add UP to the fee on the second tx

otherwise, fee on second tx would just be 546 sats x outputs... which would not be enough fee on smaller txs I think

anyway, I think having ability to specify different fees on first and second tx is better solution than what we have now, same fee for both 😉

you have to set both in the first tx because you already are maxing out fee in the 2nd

Is there value in allowing specifying of different fees on first and second tx? first tx uses outputs to encode data... second tx uses those inputs as fee... so, the difference in size (inputs / outputs) is minimal.... wont both txs always be pretty close to the same size as one another?

no the 2nd tx is much bigger

ok... inputs take up more space than outputs?

input script sig

thats where all the data is

got ya... ok, then yeah, different fees totally makes sense... if you want to write up a github issue, we can prolly get it added to next release

just allowing fee to be array is prolly simplest... but up to you 🙂

yeah i think so too, ive been doing a lot of python coding lately so i’ll check it out and submit a PR

https://github.com/CounterpartyXCP/counterparty-lib/blob/bb680ccd0f2e0128c5ca6fd6a3683a9e7c8799cc/counterpartylib/lib/api.py#L361

so there is a fee_per_kb parameter

it also looks like it will estimate fee per kb if you dont put any fee parameter in

https://mempool.space/tx/a9e86d5ade19bb43ef7fce8abe2c04a0a5120134dc492f6563a1f4d026937d93

this one is the tx

this is the dispenser:https://xchain.io/address/15nEn56DRRJKej6KWfj4FWuNzEKc63z7eR

Thanks... Does indeed appear to be a payment which SHOULD have triggered a dispense and did not... issue confirmed... got Javier digging into it now... we might want to put out a new version of CP with this fix... we have a BUNCH of big changes in the hopper for CP... but, feel it is important that we get the mempool parsing issue, and basic dispenser taproot support working ASAP.... we can hold off a bit on taproot encoding, support of larger files, and handling migrating the "file" data out of the database in the next big release.... but IMO, not having taproot support on dispensers is a big deal, and something we should rectify immediately

Thanks sir

An issue has been identified with taproot addresses not triggering dispeners.... while we dont officially support taproot encoding in CP yet (we have it coded up, just not tested for release).... I think it is important that we get support for taproot addresses in dispensers ASAP... and suggest we put out a new release 9.60.2 with the mempool and taproot dispenser fixes/updates ASAP

Also... yesterday CP had an issue with a phantom block (block that we began parsing, then reorg happened)... CP had issue rolling back the data from the phantom block... which is what caused the parsing issue on xchain (counterparty2mysql was trying to create a duplicate record)

Javier and I got xchain up and working again (removed unique index) and dug into the issue to discover the phantom block issue..... so, we ALREADY need to put out an advisory telling people to "rollback CP to x block".... otherwise, they will have duplicated records for that phantom block.

So... the timing of putting out a new minor/hotfix release lines up well... can kill 2 birds with one stone... fix current taproot and mempool issue, and get anyone running a node to update (and run the rollback at the same time)

Thoughts?

Yes, this is super important. At the very least a warning would suffice, but support is obviously better

Interesting, doesn’t Counterparty use an undo table to mitigate reorgs?

warning put up on xchain as suggested 🙂

yes... this is what I thought as well, cuz we do handle reorgs fine... I believe this is a special case where we started parsing a block and only got 1/2 way through it before new block came in.... so block we were parsing wasn't fully parsed, so not able to "rollback".... @pataegrillo can give you more of the tech details of why the "phantom block" caused issues.. sec will forward his messages here

10 duplicated

damn, surely it was a phantom block, the only fix for this is to rollback

rollback to 789146

well, here is the proof

Why didn’t we handle correctly? Is there a flaw in the cp rollback code?

because there is no handle at all in cp for phantom blocks

phantom blocks are blocks that are considered mined by many nodes but after several seconds more than half nodes accepted another block, leaving this first one orphan

for cp to handle this situation, it needs to first detect a duplicated block, then rollback everything to the block after that one and then start parsing again

well, there is another way also.... confirmations, cp accepts everything with 1 confirmation only. But it should wait for, at least, 2 confirmations

rolling back everything, even just one block, totally automatic, could be problematic

Ok… how often do we get phantom blocks? First time in 8 years I’m hearing about them😜

do you remember phantom txs I found?

like 5

well, seems like a little less than one/year

Vaguely

Ok.. so every phantom block we need to do a rollback? Worth putting out advisory or just rollback quietly n wait for any node operators to ask about duplicates?

i think you should say something about it, but if you say something about it, you should act immediately too

you know, to prevent ppl for saying that if you knew why you didn't do something about it

Ok, will clarify tomorrow n out our advisory/etc

Oh interesting, we should def think about ways to mitigate automatically, maybe a validation check of block hashes of previous 2-3 blocks during parsing

Just to ensure what Counterparty thinks is valid chain is same as what bitcoind thinks is valid chain

You could even do more since that validation check would take almost no time at all, previous 10 blocks or something

Then trigger a parsing rollback to the last matching hash if there isn’t a discrepancy

Kinda shooting ourselves in the foot here by allowing taproot dispenses... .YES, immediately allows ppl to use dispensers with taproot... but, also means ppl now have tokens trapped on taproot addresses... so, the need to support taproot is increased.... BUT, we can't support taproot and larger file sizes until we get this stamp/file data out of the database and into a filesystem

all that is to say... this update to support taproot dispenses is just putting a gun to our head to figure out the database/file de-tangle issue sooner rather than later

which is fine... but, we gotta come to consensus on how to handle "files" within CP sooner rather than later... ie, in next month or so

</end rambling thoughts... for a few minutes at least> 😛

we def shouldnt support taproot dispenses until we’ve fully integrated taproot as a wallet option

there are no counterparty wallets supporting taproot as an address option except hiro but AFAIK hiro doesnt even support sends

ok.. so, should we put out a 9.60.2 relase with only the mempool hotfix and the phantom block rollback info? leave out the taproot dispenses for now?

i think so, you have the warning on xchain now so people shouldn’t be doing it

i assume @mikeinspace is contacting hiro?

because all thats gonna happen is people will start buying shit then complaining they can’t move it

prolly.. another case where coordination could avoid all this stuff "Hey, we are hiro, do you support taproot addresses in dispensers"... "nope"... problem avoided 😛

teamwork ppl teamwork... everyone use to working in silos 😛

I’ll drop them a note but I have no idea how receptive they will be

well its on them if people continue to do it

the warning is on xchain

Warning was all I was asking for. I agree that’s enough hand-holding

yes, only so much can be done, and @mikeinspace and Stamps team is doing their best (and pretty good job) at staying on top of things.... can't avoid problems if there is no discussion, so not their fault 🙂

yeah it happens, but as soon as we realized what was going on you had it fixed within an hour or two

thx for making me aware of the issue this AM, appreciated... def an issue, dont want ppl losing funds or having a bad first experience with CP

i mean we went how long with not being able to send from p2sh?

about 6 months... tho I put out wallet update to prevent people from falling off that edge within a 1 day of discovering the issue..

exactly, and hiro isnt even a real counterparty wallet, its just pulling balance data

in that case, I could control community a bit becuase I controlled the wallet... here, not so much.

soon tho... make src-20 easy for them to integrate with APIs and balances, easy to get them to buy into CP ecosystem hopefully 🙂

yes but i think taproot support shouldnt be rolled out piecemeal

just makes it confusing

roll it all out at once

I think having src-20 on xchain and in freewallet will really make it feel more "real".... only a week or less away from that if all goes right

when its ready

we have the PR.... it is ready, just need some testing... Javier is putting the PR together this morning

also... another big thing CP needs... UNIT TESTING.... so we can avoid having to do all this manual testing on testnet...

yeah dont rush, make sure its thoroughly testing and when its ready it will be rolled out

we are close to having circle-ci working again... but still some hurdles... stopped making progress on that front about 6 months ago

chatgpt is good at that

so... if anyone looking to help out with dev... that would be a big help... being able to check code in and have unit testing do most of the testing so we can only do testing on extreme fringe cases... not normal actions

no time to dig into chatGPT yet myself... but sounds liek a great plan!

is bech32m the same as P2TR?

or is that another bitcoin address type

@pataegrillo ^^

https://whentaproot.org/

looks like its the same

actually a pretty informative site lol

there is a vscode estension using AI to generate specific tests i have tested a little and seems cool codiumAI: https://www.codium.ai/

nice

Sorry, i wasn't home. Taproot is very much alike to segwit except for the signatures and checksum, P2TR is like a P2SH with schnorr signatures and the signatures go to witness

FYI... rollback (and a new release) both require a full reparse (not a full parse thank god).... once the full reparse is completed, i'll update the bootstrap database, so that anyone who doesn't want to spend 3+ hours doing a full reparse, can just blow away their database and download the updated bootstrap, and be caught up with no reparse necessary 🙂

TLDR... CP 9.60.2 release delayed until tomorrow after reparse is done

https://github.com/CounterpartyXCP/counterparty-lib/pull/1236

All the groundwork for taproot support has been done by Javier... He will be writing up a CIP, and we'll need to get it funded before we can roll this into a release... but, some of what we need to allow stamping of large files and encoding of much larger transactions is here in this PR.. Great work Javier 🎉🚀🔥

i'll be honest, for a moment I forgot that CIP... 😔

It happens man, the space been moving at breakneck speeds... at least the hard part has been done, now we just gotta test it and get you paid for your hard work :)

To clarify... this is 1/2 of what we need for encoding larger files... we need 2 things taproot address support (this pr) and p2wsh encoding support... Javier has also been working on the p2wsh data encoding portion of things, but it requires more work... so, 1/2 way to the "stamp same filesize as ordinals" goalposts 🙂

hello guys one noob question, is there a way to cancel unconfirmed tx?

or how to use this flag for doing a double spend tx

Not easily… spending the utxos in the inputs

It’s a false message… freewallet already passed that flag with all requests

@pataegrillo we should get this message about unconfirmed flag removed…. Causes more confusion than help

Yes i think jajaj

Okey thanks

I think It Will be dump by the mempool as is 27sats/vb

How to review code changes introduced with 9.60.2 ?

im happy to try break things... I have a uncanny ability to find bugs without even looking

but yh in all seriousness I am very happy to spend some time going over stuff and testing it

github history... 9.60.2 is ONLY the mempool update... so mempool doesn't lock up when over 60k txs..

You can view the PR for the mempool update here... https://github.com/CounterpartyXCP/counterparty-lib/pull/1233/files ... been running it in production on xchain the past 2 days, seems to be working fine, mempool updating, transactions seen a few seconds after being broadcast, etc 🙂 https://github.com/CounterpartyXCP/counterparty-lib/pull/1233/files

will be putting out 9.60.2 shortly... just doing some last minute cleanup (updating bootstrap database, etc)

Sweet! Good work!

Cool! Thanks for doing all this work.

Due to the ongoing abuse of numeric assets by src-20, I want to start the conversation of requiring an xcp fee for numeric asset creation

We already require a 0.25 xcp fee for subassets which are actually numerics so I think it makes sense to stick with that 0.25 xcp amount or bump them both up to 0.5 xcp

So that all asset types are aligned in cost

Should be a very simple implementation too, validity check same as named assets

What is the main threat? Bloating the CP database?

The asset table

mysql> select count(*), sum(length(description)) from issuances where description like 'stamp:eyJwIjogInNyYy0yMC%';
+----------+--------------------------+
| count(*) | sum(length(description)) |
+----------+--------------------------+
| 6855 | 622669 |
+----------+--------------------------+
1 row in set (0.32 sec)

Basically forces anyone that would create a 2nd layer asset to use broadcasts

Close to 7000 numerics spammed in last 5 days... bloating assets table... all numerics, locked, no supply issued.. no ability to use CP in any meaningful way.

To be clear, the STAMP devs are working with us on this issue, and we hope to have src-21 released soon, and to move all this stuff to the Broadcast system from the issuance system... so, I think we can avoid having to put out an update to deal with numerics in this instance.... but, it is important to start this conversation now, cuz we will have this problem in the future if we continue to allow infinite numerics to be created with no limitations

counterparty value backed vault flying
just relevant to group, no shill.

@pataegrillo When you see this, can you please code up a PR so that we can institute a 0.25 XCP fee on numerics as joe suggested. Timing lines up, we haven't put out 9.60.2 with mempool fix yet... so, can put out this update within 24 hours with some testing.

Unfortunately this will break things for "stamps" in general as well, as they require numerics, which is not the intention, but we HAVE to stop this spamming, and discussions are not stopping it

I’m not actually opposed to this but playing devil’s advocate here: you really think that degens willing to spend hundreds of dollars will be deterred by a fee of 0.5 xcp? If anything, paying the toll just means it’s no longer even “spam” it’s just legit use by every standard. If there were 7000 named assets registered in the last 5 days would it even be called spam?

Mike, what your failing to realize is that src-20 are NOT real assets... they can NOT use XCP in any usable way, and they are spamming a numeric for every ISSUE, MINT, TRANSFER... this is not an issue about usage, or trying to force ppl to use named asseets

I want stamps to continue to use numerics... I am fine with it..

but we CAN NOT allow spamming of unusable numerics

if it does not stop, we will be force to limit ALL numerics... which is unfortunate that one project is runing things for others, and taking away the whole "You can use CP without using XCP" option, but abuse is abuse

move all this spam to broadcasts and we are fine... we want the traffic on CP.. just in a usable way that doesn't attack the systeem and slow it down

I realize it. And I’m urging the team to transition to broadcast asap.

Again, I think that SRC-21 will solve this.. and that stamp devs are on board.... but, can't wait and keep asking nicely... they could IMMEDIATELY stop the spamming... but they are not... been asking for a week, so... not like this is new news

what is needed to accelerate this transition?

just stop the spamming

None

that is it... take time to review src-21 and implement it... can use src-21 and broadcast system almost immediately... no need for some rash emergency release... I am against doing this, but our hand is being forced.

Welcome @reinamora_137 .... Sorry for not having you in here earlier, I assumed you were already in here... please take time to review and digest... we want to move things forward together, but are rapidly approaching a point where our hand is forced.

sorry for my tone bro... tend to ramble before I read sometimes... I know we are all on same team 🙂

Thanks. Definitely in queue to see how we can transition while respecting the queue of pending transactions and/ or migrating them to the new standard

Tbf stamps just exploited an issue that’s always been there, it’s something we need to address regardless

can you please stop your src-20 broadcasting service immediately to show you indicate how serious this is?

I agree, and have been against numerics... but, see the value in having a way to try xcp out... stamps onboarded a bunch of attenction to CP, dont want to stop that, just limit abuse... but that is my view, i'll go with consensus... if you guys want numerics at 0.25, I am game.

Might be a good idea to pause aside from this issue: we need a proper indexer to avoid overmints.

I can’t really just turn it off until we have a working setup that can continue moving the queue into valid broadcast transactions

ok... @pataegrillo please get this PR ready, numeric spamming will stop within 24 hours, and unfortunately, this means STAMPS project has no way to mint either.

asked nicely, but this is bullshit

you can stop service immediate, your not... done asking nicely.

Last I heard you agreed to give us a week to work it out

I was under the impression that you were going to pause service

not stomp on the gas

Nobody stomped on the gas

I give you a week, we are at 30-50K assets

We are just servicing demand

https://i.gyazo.com/ea1f3a5a441a2e150e37934afa34604e.png

This is stomping on the gas

Are there any other services using numerics?

Understood... was hoping we could place nice together and you could migrate to SRC-20... but if your going to continue abusing CP because you can, your forcing our hand. Thank you for FINALLY making it clear you have no intention to stop spamming while you can.

Subassets and STAMPS are the only meaningful usage AFAIK

Calling Javier now... PR should be up within a couple hours... can push this out the door and update xchain and api.counterparty in 3-4 hours

Giving us a week and time to swap to the new technique is playing nicely from last I heard is all.

playing nicely is understanding your abusing the system and pausing service the last week I have been asking... i've been patient, been asking every 24 hours, updating ppl on issue.

If you wanted to show you were good citizen of CP and that stamps was responsible project, you would play bal

but, IMO you have short-term in sight, and have clarified that your operating service to profit, so this will continue as long as we allow it

Imo we are playing ball that’s why we are engaged in the open discussion. In either case we could pause accepting new trx for a bit but we still need to process the queue of backlogged items

Was hoping there was some "community" pull here.... looking out for the other projects on the platform, but doesn't seem to be that way, since you continue spamming even though you know it is serious issue, so, our hand is forced, Stamps project will be unable to operate at all in 5 hours... paint me as the bad guy, however you want.... but we both know I did EVERYTHING I could to avoid this (and have code and history to proove it)

Imo this is not a stamps specific problem, stamps just exposed the issue and risk surface that’s always been there

Threatening to disrupt our revenue stream is not productive

Cmon bro.... enough with the games.... "we can close the door, but gotta process the queue"... you shoulda done that a while ago... you could pausse the queue now and mint all as SRC-21.... your just blowing smoke

You just need to switch to broadcasts, this forces your hand

I REALLY wanted to avoid this... god damnit

Yeah we will switch to broadcast that’s never been a question. I just haven’t had the time to properly implement.

now im gonna look like the bad guy cuz some project comes in and refuses to participate in teh community and just spams the system for profit.... opportunity for stamps and counterparty to cooperate and build dope shit squanderd

it is simple

You just have to consider we have a platform here with millions of dollars worth of assets on it that is being degraded because of an attack surface that’s been exposed

stop your que immediately, or we fork in 5 hours. full stop.

We need to shrink the attack surface now that it’s exposed that’s all

It needs to be done regardless

I’m going to try and make a recommendation: if the issue is xcp burn, would a retroactive burning of xcp solve this at all?

I don’t think this is helpful

ok.. will stop and just move forward with fork

just upset cuz this is squanderd opportunity and not good for CP/Stamps... but your right.

I think an announcement once update is in place with a block activation and just leave it at that

Nope, issue is spamming, spamming wont stop until fixed on protocol level.

usage of XCP is not a factor here... would remove numerics entirely, but fee is fastest way to stop

Can’t remove numerics, have to just move forward

And we already have an xcp fee for numerics when they’re subassets

It’s not really a stretch

Guys

This really got out of hand

Agreed

@reinamora_137 @Stampchainofficial I’d like you to really consider the trade offs here.

What's with all the threats. I though we had agreed to work together to fix this

Let just calm down and sort it out

It'd very bad to expose all this

Maxis will gave a field day with all of us

They don’t give a shit

We have a big queue we need to process and I don't want to turn of my revenue stream without knowing how I will get it back

Even less ok

But help me help you

Please

You don’t have to add to the queue. This is very short term thinking, your revenue stream goes away if they kill numerics

This is not the time Dan!

Honestly a brief pause will actually be GOOD as we don’t have proper tooling or marketplace yet.

And that demand doesn’t go away it just gets pent-up

We could have win-win here no need for lose-lose

I have a call with Sovryn tomorrow. Real integrations are about to happen. Now is not the time for this sort of shit

This is the problem... chasing profit over caring WTF the community thinks.... we asked nice, I offered you $1000 of my own money to pause service and migrate to src-21.... you said nope, wanna keep spamming numerics... our hand has been forced

About to put out this statement to STAMPs and CP channels... FYI

It is with a very heavy heart that I make this announcement, but ... Here goes

SRC-20 is using Counterparty in a very abusive way (spamming numeric assets with no supply and locked). In addition, SRC-20 is spamming numerics not only for DEPLOY actions, but a numeric asset is being created for EVERY DEPLOY, MINT, and TRANSFER action.

Myself and other Counterparty devs have been in discussion with the STAMPs devs, and made them aware of this issue earlier this week. Since that time we have consistently repeated that this is an issue, that it is abuse, and that it needs to stop.

Myself and other CP devs have gone out of our way to work with the Bitcoin Stamp devs to find a solution that works for everyone, and allows this exciting growth to continue on Counterparty, but in a way that makes sense and does not abuse the system.

Over the past week over 7000+ numeric assets have been spammed, and after repeatedly asking the STAMP devs to pause their minting service, and to work with us to transition to a better spec, there has been minimal participation, and the abuse has continued.

We are now at a critical point where Counterparty Developer community is being FORCED to put out a emergency hotfix for this issue by instituting a 0.25 XCP fee on all numerics, to bring them in line with the 0.25 XCP anti-spam fee used on subassets (numerics).

This has been a VERY stressful week for many of us, and we DO NOT take this decision lightly.

What does this mean to the STAMPS Community?

1. STAMPS will no longer be able to operate on Counterparty, people will no longer be able to mint numeric stamps using only BTC, and this will effectively kill off the stamps projects ability to mint tokens on Counterparty.

2. SRC-20 is considered an "attack" on Counterparty, and any tokens or TICK registered on SRC-20 will not be usable in Freewallet or on tokenstamps.io.

I spent the past 48 hours writing up some new specifications (which I was hoping the stamp devs would write), which establish 2 new systems. The Broadcast Token Name System (BTNS) and SRC-21. These 2 specs will allow the new "SRC" system to continue experimenting on Counterparty, but in a way that is responsible.

It is unfortunate that the src-20 madness will force the disabiling of numerics, therby breaking ALL stamps on Counterparty, but this is where we are.

https://github.com/jdogresorg/stampchain/blob/main/docs/broadcast-token-naming-system.md

https://github.com/jdogresorg/stampchain/blob/main/docs/src21.md

yeah we can stop accepting new mints that's not a big issue and not opposed to that. prior to this chat it appeared we had a week, and now all the sudden it's a matter of hours simply over a database? we just need to clear the queue of pending trx without major disruption would be ideal. i don't need the drama. its fkn saturday and looking to chill with the family.

We have had no time

I haven't needed the drama all week.... but i've been asking nicely.

Can we commit to this like right now? Like within the hour as a good faith gesture?

If spamming stops, no need to force release in a few hours, we all can breathe, and move forward on src-21

I think a compromise is in best interest of everyone

i don't have any problem with stopping to accept any new transactions within 1 hour from now. i'm more concerned about being able to finish processing the backlog. if that's not acceptable we can just shut the whole damn thing down and CP can go back to the way it was. not a big deal to me and i can enjoy the rest of the saturday night and you guys can push whatever fixes you need.

I think that’s all that’s being requested

It would be great if we could agree to this

Are we agreed?

How many txs are in the backlog?

not agreeing till I know damage.... not saying yes to 5K more mints

If money has been taken I understand wanting to see that through. But should stop new ones asap

Come on bro