I am against an imminent fork. Some issues need to be sorted out (not src related).
Heading to bed now, will open github issues in the morning.
- 01 June 2023 (14 messages)
-
-
What is the imminent fork this time?? 😑 -
Hahaha nothing to worry about Juan -
Just another day in Counterparty land
-
I also figured out why we forked at that weird taproot address
-
Python-bitcoinlib doesn’t support taproot and Javier had created his own fork for adding support which jdog had deployed on the node powering xchain
-
Luckily nothing spent from that address
-
This is so wrong (the jdog deployed part)
-
The problem is from this transaction correct? This was way before the release
-
It was a mistake done in haste
-
Wasn’t malicious
-
Well then what is it going to be? Will the v9.60.2 release stay? Are the hashes from this release different from v9.60.1 or where does the bug stand in terms of the hashes
-
He’s reparsing from that block forward with the correct version of bitcoinlib
-
This should fix the hashes
- 02 June 2023 (4 messages)
-
I've posted some CIP29 issues on Github. Shouldn't be a party stopper, but would like these to be resolved before going ahead with the update.
https://github.com/CounterpartyXCP/cips/issuesIssues · CounterpartyXCP/cipsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Did some performance testing.
https://forums.counterparty.io/t/testing-scalability-of-assets-and-issuances-tables/6621/3Testing Scalability of 'Assets' and 'Issuances' TablesI’ve simulated inserting rows into the assets and issuances tables and measured the performance. The initial DB is a real, recent Counterparty DB. The added rows are random values of the same format as real values. Assets Milliseconds to look up a name: The performance is worse than O(n) 😱 Issuances Counting the number of rows for given names. Even worse… Python scripts used for testing. Assets: db_file = 'db_copy.db' #latest Counterparty DB import os dir_path = os.path....
-
CIP29 - Correct assumption on node impact? · Issue #82 · CounterpartyXCP/cips
The motivation for CIP29 is: "Balance the cost of issuing assets with that of running nodes/infrastructure, and to encourage use of broadcasts when issuances are not strictly needed." @jo...
-
Joined. - 03 June 2023 (1 messages)
-
Welcome!
- 06 June 2023 (10 messages)
-
A summary of possible dispenser solutions. https://forums.counterparty.io/t/solutions-to-rugspenser-problem/6623Solutions to "rugspenser" problem
Attack vector: Scammer detects incoming buy and immediately sends another buy transaction with a higher fee. The scammer’s tx gets priority and the legit buyer loses his bitcoins. Possible solutions: 1. Pre-payment before full payment This requires a protocol change. The logic is simple. If less than a full dispense is detected, allow up to 12 blocks for the second tx. Perfectly safe as the protocol keeps the token on escrow. The buyer, if not trusting the seller, can thus make a tiny pre-pa...
-
Another option is for the dispenser to allow-list addresses
-
Serious related question: why continue using a separate obscure platform for discussion instead of having it all in GitHub?
-
I though github was for issues. Forum more for informally discussions ?
-
On the protocol level?
-
Yeah it would have to be a protocol change for that one
-
Maybe that was the purpose of creating a forum, but in my opinion all protocol related conversations should be made in the protocol repo!
The informal conversations are in Telegram now as I see it -
yeah makes a lot of sense to just have this discussion right on github
-
I would say all of them
-
Yep
- 07 June 2023 (9 messages)
-
Who is running twitter.com/CounterpartyXCP ?
I see the last retweet being critical about SRC20…
But then the previous* tweet (one in between) is the announcement of BTNS420…
Why take a stand? Why the “official” account is promoting an alternative naming system?
I’m with @jp_janssen that all references to alternative naming systems should be removed from “official” sources. He made an issue about this https://github.com/CounterpartyXCP/cips/issues/74Counterparty (@CounterpartyXCP) on XThe #Bitcoin protocol to create tokens and #NFTs. Tokenizing on Bitcoin (BTC) since 2014. Telegram : https://t.co/OvscgMMSpa Discord: https://t.co/LXUzrZHvzU
-
SRC-20 aside (I know its controversial), I do find it funny that one RT is about how "stamps isn't a real protocol" because its just "rebranded" Counterparty, while another RT is about how "XCP-20" is the "next big thing!". -
They both basically use the same approach of "rebranding"
-
Haha yeah I saw that today pretty hilarious -
Personally, I think the Counterparty Twitter should stick to Counterparty protocol neutrality
-
And the brc token inside a btc token lol
-
Yeah you would think
-
Yep I would just remove both tweets.
And the one “in between” is promoting Rude Relics. Taking about parasites, that one can be considered a virus. All reset assets: https://www.xcp.dev/wallet#1RUDEjgtMCY8kSJUUvTv4KHMGFgg9LrgF -
Anyways, no real objection as to how the account is run. Just my personal "opinion" that an account representing the protocol should probably not editorialize or have a bias. It's meant to disseminate information about the protocol. Like "Here is the latest release..."
- 08 June 2023 (11 messages)
-
I think I have access via tweetdeck, I can scrub those
-
I'm not making the request. Just my opinion about how a twitter account should be run for a protocol.
-
It just seems schizophrenic for the account to RT my podcast appearance about stamps and then deride stamps 3 tweets later
-
Lol sounds perfectly acceptable for twitter
-
anyways, my opinion is all news is good news. Every twitter mention about stamps helps stamps
-
Looking at the latest tweets… I just cannot support it. Have to unfollow, I don’t like the vibe of it
-
I'm not a fan of labeling anything "official"
-
I try to always put it in “quotes”. Agree
-
i love that theres no official ordinals twitter
-
CounterpartyXCP/cips · Discussions
Explore the GitHub Discussions forum for CounterpartyXCP cips. Discuss code, ask questions & collaborate with the developer community.
-
just enabled discussions on cips repo
- 10 June 2023 (1 messages)
-
https://github.com/CounterpartyXCP/cips/discussions/87
How we can squeeze some improvements into the asset ID system
A. A assets can be introduced.
B. 1-3 letter assets.
C. Make subasset IDs deterministict so light wallets won't need to trust API.Possible Improvements to Asset Names & IDs · CounterpartyXCP/cips · Discussion #87All assets have a unique ID. The ID is what's inside Counterparty message data. For named asset a mathematical two-way function links the name to the ID and vice versa. Unfortunately, due to a ...
- 11 June 2023 (4 messages)
-
Whats the deal with the description field in XCP? I cant keep up with the ***-20 and drama. Is the description field character length on the chopping block? I believe I remember J someone talking about that recently. -
Why you say the length is on the chopping block?
-
It was discussed here but nothing has been submitted about that to the repo as far as I know
-
First I’m hearing that
- 12 June 2023 (7 messages)
-
Limiting the description field length would severely hinder base64 and stamp use in counterparty. As above, I’m not positive about this, who said it or when in all of the recent chaos. I might be imagining things.
-
So here is my understanding of the situation. Base64 "Stamps" are not really the contentious issue. In fact, Jdog RAISED the description cap in Freewallet to accomodate for Base64 "Stamps" minting where, prior, it was almost impossible (200 character limit).
The area of contention is SRC-20. SRC-20 is a fungible token standard built on Stamps but use zero supply numerics as the means by which they are deployed/minted/transfered does not utilize traditional Counterparty methods like Dispensers. SRC-20 is being pivoted away from using asset issuances.
As far as I'm aware, there is no current effort to hinder base64 stamps when it comes to the "art" usecase. -
...but things are always fluid... so we'll see what happens.
-
You’re awesome. Thanks for taking the time to iron that out.
-
The protocol allows long descriptions and stamps are taking advantage of that. And have been the very successful in growing Counterparty with cool minimalistic on-chain art, like the opposite approach to high data inscriptions. I really like them and believe they should be embraced.
But these long description do bring a problem with a denormalized (unnecessarily duplicated) database.
The zero quantity lock assets I don’t agree are a new problem. Is just the same as the above, the unnecessary data duplication.
I think the best move to dissuade from the meta^2 layer like SRC-20 tokens done on numerics is to add a fee to issue numeric assets. -
Then with the necessary time try to fix as much as possible of the duplicated data problems in the protocol.
-
Thanks friends for the kind and intelligent conversation.
- 13 June 2023 (135 messages)
-
hello guys, i have a question, and i think here are so many talent to ask, im trying to get a way to once i have the Hiro wallet connected to my site and i am able to see the assets of the wallet a way to create a transaction for transfer and that users just have to sign -
i found this repo https://github.com/Jpja/CounterTools from @jp_janssen and thinking if i can use it in some way
-
counterparty-hw/xcp.js at f9156fe69204a05b8634413a72525db0979371ca · loon3/counterparty-hw
Counterparty wallet for use with Ledger Nano S / S Plus / X - counterparty-hw/xcp.js at f9156fe69204a05b8634413a72525db0979371ca · loon3/counterparty-hw
-
You can pull the js functions right from here if you don’t want to use Counterparty api
-
I dont want to have a full node for it
-
But im fine with counterparty API if i can find a way to use it
-
You don’t need a full node but you do need a way to construct and sign txs
-
I think that with the micro-stack library i can sign tx
-
Because of the way Counterparty encodes the data you also need to have coin control as in you need to know what utxos are being used as inputs and the order they are in the Tx
-
Is this something hiro uses?
-
Hiro recomends two libraries to interact with their wallet
-
You’ll also need to query a node or xchain api to get asset balances
-
i have assets balance right now
-
i just need a way to create and sign this tx
-
i didnt understand this
-
i have lot to learn and i dont find any docu i will follow this new thread, thanks!
-
what wallet did u use to sign for the original project?
-
what do you mean?
-
ive used two libraries, bitcore and bitcoinjs-lib
-
i dont think bitcore is maintained anymore
-
and you connected the ledger directly?
-
yep, rpw.wtf is the latest version
-
connecting directly with ledger eliminates the need for a browser extension
-
okey
-
but i think the reality is that people want the convenience of a wallet directly on their device
-
i use both now
-
https://hirowallet.gitbook.io/developers/bitcoin/sign-transactions/fully-signed-bitcoin-transactionsSending bitcoin
Sign and broadcast Bitcoin transactions
-
-
this is what you want
-
but is psbt
-
Methods & Events | btckit
draft, subject to change
-
but what is the method i need?
-
bitcoinjs-lib standard is to create all txs as psbts now
-
thanks for your help bro
-
so any tx can be a psbt
-
mmm okeyy
-
i love this docs full of todos 😞
-
okey so maybe with this and your repo i can do something
-
yep, i might work on packaging some functions
-
so you can just use npm
-
that would be awesome
-
also im interested in learning how it works so maybe i can help with that
-
or at least being reading all your commits
-
you should familiarize yourself with bitcoinjs-lib
-
it does all the heavy lifting
-
also i think i see in a group but as there are 100 of counterparty dev groups i cant find it anymore a good gist explaining how was done the raw tx that is encoded in OP_RETURN
-
everything else is just pulling data from APIs
-
i will
-
but i think hiro uses this
-
yes but you need to build the psbt
-
then you use btckit to sign the inputs
-
okey im going to read it
-
thanks
-
but psbt are possible with xcp assets im still confussed i thought it was just for taproot
-
psbt is just a standard for building bitcoin transactions
-
psbts allow for things like atomic swaps for ordinals (openordex) but thats not the only use case
-
sorry im really new to Bitcoin i need more reading but with this i have something to start reading i was a little blocked
-
yes this was the first time i eared this word
-
okey so with this standard i can build any kind of transactions for example a counterparty asset transfer
-
okey i need more reading on this
-
thanks really appreciate your help
-
yep exactly
-
bitcoinjs-lib/test/integration/transactions.spec.ts at master · bitcoinjs/bitcoinjs-lib
A javascript Bitcoin library for node.js and browsers. - bitcoinjs/bitcoinjs-lib
-
one thing to keep in mind is that counterparty message data is rc4 encrypted using the txid of the first input (which is why you need coin control)
-
this is replacing data?
-
you would put counterparty message data in the op_return output
-
the counterparty message data is what you build in your code? here?https://github.com/loon3/counterparty-hw/blob/f9156fe69204a05b8634413a72525db0979371ca/lib/xcp.js#L114counterparty-hw/xcp.js at f9156fe69204a05b8634413a72525db0979371ca · loon3/counterparty-hw
Counterparty wallet for use with Ledger Nano S / S Plus / X - counterparty-hw/xcp.js at f9156fe69204a05b8634413a72525db0979371ca · loon3/counterparty-hw
-
yep
-
and in the body of transaction, because this example is sending actually funds i just put dust in it?
-
or just 'broadcast' this OP_RETURN counterparty message?
-
the tx has two outputs, an op_return and a change output
-
the only amount spent is the tx fee
-
okey that it
-
You might be looking for this: https://jpjanssen.com/compressed-xcp-transactions/ -
This is the future of Counterparty. Love it
-
I Will check it too
-
Do you think that the psbt aproach is not interesting for not need to implement all counterparty-lib?
-
Very interesting
-
Thanks for share
-
Thia is just a propossal or the XCP prefix is also valid?
-
its a proposal
-
also @uanbtc im running 9.60.2 now and ledger, txlist, message hashes all match your node
-
Nice! Without bootstrap?
-
i used the 9.60.1 bootstrap
-
since that one was known to match yours previously
-
Got it.
-
but good to know it was just a bad library and not an actual consensus fork with xchain
-
For sure
-
did you see my ordinal envelope proposal? curious what your thoughts are
-
Just read it again. Your proposal (as of now) would mean adding ord satoshi tracking to the fednode stack correct?
-
yes, but it doesn’t necessarily need to be ord, just an indexer that follows ordinal theory
-
so all the inscription specific code in ord wouldn’t be necessary
-
Yeah. It is super interesting for sure…
Haha that’s what I was going to write about! That I feel the inscription data is something less complex that can add a lot of value to the current Counterparty -
Inscribing by itself, without sat tracking
-
yeah its a better p2sh encoding
-
Your proposal is about sending 1 unit of an asset right? Not like the issuance privileges of the asset
-
yes as it is now, the only action proposed for assets held in a sat would be to transfer them to another address
-
but theres no reason additional functionality couldnt be added
-
We are getting close to something you know I believe in. We should get rid of the divisibility
-
the two-way peg mechanism allows for any counterparty message and the sat burn via op_return is a validity check
-
That’s what would need to happen for this to make sense
-
issue via sat is def possible
-
actually
-
you dont even need to, you can issue and transfer to sat
-
This I didn’t get too well because wouldn’t that destroy the originally sent unit also?
-
the sat is an envelope with an address (sat id)
-
Well yeah, my point being that CP divisibility is irrelevant
-
so the sat id is just another address type, the difference being to perform an action from that address you need to burn the sat
-
Is ord actually tracking the sat burning? I know it was like an idea but not sure if it is integrated and accounted for
-
of course it has to track all sats
-
i wrote a simple daemon that identifies txs with sat burns via bitcoin rpc then gets the sat id from ord
-
Well yeah… but is it like actively destroying the appropriate sat? I guess it is
-
Anyway… before that I think that counterparty-lib, like ord, should be fully self contained meaning that addressindxr should be part of it
-
i agree, but it probly would require a rewrite of counterparty-lib in something like rust first
-
which is no small task
-
Agree, and addrsindx is already rust so that is the side to go
-
yep and so is ord
-
Yep
-
time to learn rust lol
-
I did for a bit, have a fork if ord that is just about inscribing no sat tracking
https://github.com/jotapea/pubGitHub - jotapea/pubContribute to jotapea/pub development by creating an account on GitHub.
-
I’ve been thinking about what the next counterparty-lib hard fork (v9.61) should be about… I would limit it to a few simple but very crucial changes.
1. Fee for numeric asset issuance
2. Issuance message format revert (meaning…)
3. No more reset assets
1 is already quite understood why the need. But 2 and 3 are about going back into the drawing board to come up with a well thought update to the issuances / DB that can accommodate the recent growth. And acknowledging that resets as implemented were not a good move (what to do about the already reset assets will depend on the new issuance design that is decided).
All these with a block activation with enough anticipation 1+ months after the software is fully tested and working well -
no. 2 is a no-brainer, the new issuance format should have always been a new message id and even javier has recognized that was a mistake
-
i think you could get people on board with removing the reset if divisibility is addressed
-
because thats the only reason reset exists
-
Yeah. I would say remove it! But no need to anticipate that, that will come later
-
divisiblity should be something the client does, just like bitcoin divisibility
-
I think the problem at the protocol comes with orders and dispenses, which do consider it
-
sends too, you have to be aware of it before performing any function with an asset qty
-
or else you risk sending the wrong amount
-
Well but sends is still just interpretation of an integer. For the orders / dispenses is is actually considered as part of the trade math
-
oh interesting, seems odd
-
why not just use integers
-
Well yes the source are all integers still
-
i guess i dont follow then why its different, orders just see a divisible assets as 100000000 units instead of 1
-
Yes maybe I shouldn’t have said math, because the math will still be done at the integer level true
- 14 June 2023 (1 messages)
-
A partial solution here. Table with divisibility for all locked assets, so light wallets won't need to trust api.
Problem is that new and unlocked assets still need api.
https://github.com/Jpja/Electrum-Counterparty/tree/master/dbElectrum-Counterparty/db at master · Jpja/Electrum-CounterpartyGenerate OP_RETURN for sending Counterparty tokens from Electrum - Jpja/Electrum-Counterparty
- 15 June 2023 (3 messages)
-
@hodlencoinfield is your node returning results for the mempool table?
-
yep
-
Ok thanks
- 16 June 2023 (6 messages)
-
Hello! Im working on psbt transfers, thanks for tour resources, Im having some problems with bitcoinjslib working on the browser any suggestions?
-
Most of the functions works well the problem is for creating the Psbt object is required a Buffer and Buffer is not available in browsers
-
if i do with buffer there is other different error
-
-
@hodlencoinfield i dm you as im using your repo as reference
-
thanks guys
- 20 June 2023 (9 messages)
-
Thanks for your help and resources, i have done great advances (For me at least jejeje) so far and learn a lot but still in progress, i have achieved to build and sign a PSBT tx with the OP_RETURN but i think that im missing something, also idk why there are not outputs in the decoded json of the tx (im using this web to decode: https://chainquery.com/bitcoin-cli/decodepsbt) i add the json of the tx too so if anyone can help me to debug and create a valid XCP PSBTbitcoin-cli decodepsbt – ChainQuery
The decodepsbt command returns a JSON object representing the serialized, base64-encoded partially signed Bitcoin transaction.
-
-
can you share your script?
-
yes bro
-
Untitled file — Codefile
Create collaborative code files online for your technical interviews, pair programming, teaching, etc.
-
this is the script im using
-
did you had the time to check it bro? @hodlencoinfield
-
I haven’t, will look tonight
-
Thanks ser if you need more info off what im using let me know
- 21 June 2023 (26 messages)
-
also, does anyone knows why is being used this 5459 to retrieve the change? i think i have seen it in other places too
-
its a legacy number for checking if output would be below the dust limit
-
dust limit used to be 5460 but is now 546 so you can adjust to that
-
basically if the remaining satoshis from the input are less than the dust limit, they’re added to miner fee rather than change output
-
mm okey
-
i think one of my problems is that im not adding the change properly but i think is because im not calculating the good miner fee
-
okey i will update to 546
-
i see a tricky way to aproximate the size of the tx based on the number of utxo and multiplying it but idk if is a good idea..
-
export function calculateAproxFee(utxoCount: number, outputCount: number, feeRate: number): number {
const estimatedTxSize = utxoCount * 68 + outputCount * 31 + 10;
const totalTxFee = estimatedTxSize * feeRate;
return totalTxFee;
} -
you dont know the number of utxos until you know the total amount
-
this is why fee estimation is hard
-
the easier way is to use a standard tx size and calculate fees based on that
-
thats a problem yes
-
what do you mean?
-
if you’re creating a counterparty tx then generally you’ll have a single input, an opreturn output and a change output
-
a hardcodes stimated size for a transfer tx?
-
generaly yes
-
and in my case i think always as this wallet have been just receiving assets
-
which is 249 bytes assuming p2pkh
-
so calculate fee using nextblock sat/byte and use that number to determine utxo needed
-
lets try this thanks bro
-
and when i know how many utxo need i can do this check?
-
i think i gotch it
-
-
yes assuming txFeeSatoshis is the rate sat/byte then you’re good
-
thankyou ser
