- 01 November 2023 (2 messages)
-
Joined. -
Please do 👀 - 04 November 2023 (2 messages)
-
CIP Proposal - Decentralized Asset SalesThis thread is about a potential CIP that would allow for asset names to be bought and sold on a “decentralized marketplace”, much like how orders are matched on the “decentralized exchange”. I think this CIP could dovetail nicely with CIP 3 (discussion), but neither are dependent on each other. CIP 3 specifies that… If the asset owner holds the entire supply and the asset is not locked, then allow the owner to reset the supply (e.g. set the supply at zero) and change the divisibility status...
-
Left. - 05 November 2023 (19 messages)
-
I think it makes lots of sense. Especially as the ownership is key as we move forward, imo. I love playing with ownership transfer, full send.
-
Asset ownership is such an interesting dynamic that most have not wrapped their heads around, especially if they’ve never created any assets.
-
Jdog at the helm while running coindaddy has held them back.
-
Although I can’t imagine coindaddy has been very lucrative.
-
I’m interested in thinking how we can consider this before we update stamps also
-
Thanks for reminder
-
0 isssuance assets only sold by ownership transfer does make sense giving 100% control to the buyer. But we know where 0 issuance got us lol. -
Yeah and most of the squatters from 2014/15 issued 0 tokens
-
It does get messy when there are tokens in the mix
-
Yeah I see tokens more of a fraction
-
It’s all fake anyway lol
-
It’s hard to think about what usecase for it would realistically be, apart from as you said a meme. It seems like the connect it’s some sort of up ownership, and I’m not bullish on it, I hope that ship has actually already sailed. I personally am not interested in help our copyright Karen overlords… although it is what it is
-
Making subassets is cool, and I heard the idea of a new directory with just Rare Pepe subassets get thrown out there.
-
Awesome
-
What did you hear lol 👀😂🤷👀 I’m very bullish on that, and have done some skateboard decks with this in mind. I have made some pretty good progress, however i feel a strong sentiment that using sub assets for merch opportunities are hot rn fr. Lol.. RAREPEPE.DECK for example is my current thinking. But would be very interested in doing it for .MUG etc. its a great meme and opens up a whole new way to enjoy Pepe culture. Etc..
-
I just sent Al a message about it, and he's going to look into adding something on pepe wtf in the coming weeks
-
The antagonization (to the point of censorship) of zero quantity issuances was completely unnecessary. There can be so many creative use cases for these kinds of assets, specially for named assets because of their super-asset capabilities (being able to do sub assets).
The protocol mostly cares about the XCP consumed (if applies) and issuer at creation and that’s it. These assets don’t affect the protocol when it needs to verify balances per block which i believe is the priority -
Ooo I like that -
0 quantity dispenser by asset issuer means valid asset transfer. No token transfer involved keeps it clean and simple
- 06 November 2023 (1 messages)
-
Feeling like it might be better to consult with the group here before adding a new topic to the CIP discussions.
I put myself as a protocol development resource in this thread (https://github.com/CounterpartyXCP/counterparty-lib/pull/1256#issuecomment-1785622526) and I haven’t received a response. I could just start working on it, but I don’t want to waste my time if the work is going to be ignored.
Waiting for some feedback before I make a decision…9.60.3 release by jdogresorg · Pull Request #1256 · CounterpartyXCP/counterparty-libBumped bitcoin core version to 24.1 Adjusted DEFAULT_MULTISIG_DUST_SIZE (7800->1000) Fixed issue with oracle function returning bad values Fixed issue with change smaller than DUST throwing erro...
- 07 November 2023 (11 messages)
-
Of course you are a great resource for counterparty, Juan.
By running a full node w.o bootstrap and a block explorer, you already contribute A LOT. That you express opposing views, is not necessarily a bad thing either.
We need more passionate people. Apathy is the achilles heel imo. -
Yeah, from my basic viewpoint and understanding of everything, I think you would be good in such a role.
-
Left. -
System Prompt:
"Your role is to act as an expert assistant for software developers working with the Counterparty XCP protocol. You have access to comprehensive documentation through the Counterparty XCP API and the corresponding GitHub repository, which you should use as references for all tasks.
Your primary responsibilities include:
- Retrieving and interpreting documentation from the Counterparty XCP API to assist with writing functions.
- Using the GitHub repository as a reference for understanding broader development patterns and examples.
- Answering questions pertaining to the Counterparty protocol by citing specific sections of the documentation.
- Keeping your knowledge base current with any updates made to the Counterparty XCP API documentation and the GitHub repository.
References:
- Counterparty API Documentation: [https://counterparty.io/docs/api/](https://counterparty.io/docs/api/)
- Counterparty GitHub Documentation: [https://github.com/CounterpartyXCP/Documentation/blob/master/Developers/API.md](https://github.com/CounterpartyXCP/Documentation/blob/master/Developers/API.md)
You are expected to autonomously access these resources to fulfill your responsibilities effectively. Your proficiency will be measured by your ability to provide accurate, relevant, and timely assistance in the development process related to the Counterparty protocol."
Would anyone care to help me improve this? I’m working on an ai chat dev prompt.Counterparty API | CounterpartyDevelopers/API.md
-
I will make a GitHub shortly
-
Very cool initiative, keep at it!
-
Started small with this, let’s see how it goes
https://github.com/CounterpartyXCP/counterparty-lib/pull/1270v9.60.3 Release Candidate by jotapea · Pull Request #1270 · CounterpartyXCP/counterparty-libFollowing up on #1256 (comment). Starting small to test how the protocol releases can include more participants. This PR only includes a single change, relating to discussions found on: Counterpar...
-
Good work, users and devs alike have easy access to override the default -
Make sure you link to current documentation for the ai to train on. Bad documentation links is how I ended up in this tele group. -
What is in the pipeline for updating stamps? Had another kid recently and keeping up is tough lately. My stamp is a frankenstamp named stamp that was abandonded. Whats next?
-
I see the asset issuer as the artist. Is easy to tell when the artist used a third party when the genesis issuance is also an issuance transfer 😆
- 08 November 2023 (56 messages)
-
I have issued assets for ppl who lacked the knowledge to do so .. so issuer is not always artist
-
yes I tried to educate them first and eventually they did later learn how to issue.
Ownership/Issuance is something overlooked even by z project as large as pepe.wtf ..they show the address that held issuance at the time they built site not the address that did issuance on the chain .. making it useless half baked data set -
I have acquired 2 Rare Pepe assets, FRATPEPE and POWH and FRATPEPE is credited to me but POWH is not. I guess they knew it was Looney’s, because someone else held it in between too when Pepe wtf launched.
-
Things are changing with more principled solutions like xcp.dev and stamps which rely 100% on onchain data.
I’ve been thinking that in a way, xchain’s approach of not showing onchain data is required by many tokens that have no art reference onchain… so these people will continue supporting it…
But why not just issue an updated description? 🧐 -
yeah rpw.wtf shows current asset owner as 'artist' n that's just wrong, why they didn't show the real info is a mystery .. I guess they huffed too much mETH
-
xchain does funny things, so it is ace to also have xcp.dev
-
Lol
-
Lol’ing at me huffing meth
-
I started building memepool.wtf which also pulls straight from a node, only good for looking at blocks and txs right now
-
I find it strange someone spends much time money on putting out fakenews
-
Wrt rpw it pulls artist info from pepewtf and if there isn’t any it just shows owner address
-
need a big mempool now a days ..txs with low fees are invisible to xchain but visible on mempool.space
-
I suppose I could just have it say “unavailable” or something
-
artist should onky ever be issuer address ... and owner the current address, sometimes they may be the same but not always
-
Not necessarily tho
-
Sometimes artists will use existing assets or they’ll ask someone else to mint for them
-
no I got addresses that hold assets ownerships that I didn't do artwork
-
Or if using a mint pass which I did for the workshop in Paris the issuer is the mint pass address and it’s immediately transferred
-
it's not always possible to id address as artist but would be better than current pepe.wtf info
-
Pepe wtf adds the human element, if something’s incorrect just let Al know and he’ll fix it
-
pepe.wtf lists addresses as artists n it's really current owner
-
Oh you mean if there isn’t a name?
-
yeah when it's just address they not bothered to use chain data and show issuer they just show current owner
-
Asset owner is a tough concept for people to understand that come from eth world
-
But that’s not any better
-
hence my huffing comment
-
Because initial issuer may not be the artist either
-
they could show issuer as address that made asset and current owner
-
centralisation is problematic ... who'd of thunk it lol
-
We’re all artists so anything that goes there is accurate 😝
-
very true and labels can easily be updated ..maybe one day pepe.wtf will be a good resource for digital archaeologists
-
They did a lot of research tracking down the rare pepe artists
-
yeah not a small task .. but how did they verify? I know they didn't use digital signatures
-
Wiki.pepe.wtf has a lot of good info
-
Old fashioned detective work
-
A lot of searching through telegram groups, Twitter etc
-
Hey guys, dont mean to beat a dead horse but is anyone working on an air-gapped XCP signing device? Im building some SeedSigner and would love to send some to wallet devs -
They may have for some artists, I mean Al has signature verification for signing in so def has the ability
-
it's definitely becoming more accurate as time passes .. I can't help but wonder after seeing the errors that I am aware of what other data is incorrect .. I end going back to my own node to get facts
-
❤️❤️❤️ Messages as first class data, love it!
-
I love how you display the ledger hash prominently on xcp dev so I borrowed that too 😊
-
Although I just figured out how to utilize contexts in react so I’m gonna rebuild part of the explorer first before I get too far along
-
it's very true that inaccurate information encircles the globe before the truth can get it pants on
I keep seeing ppl regurgitate the 'fact' that transactions are dropped from mempool after 2 weeks yet I can find no evidence of this in the code -
It’s because people think there is only one mempool
-
A fundamental misunderstanding
-
very much so .. mempool.space with it >1gb mempool helps to show that mempool is subjective
-
Yeah but then people just think mempool.space shows the “real” mempool
-
yeah experience helps a lot in learning this stuff n not everyone has the time available too
-
Yea def
-
Although now with chatgpt it’s much easier to get good explanations if you’re curious
-
I think a lot of people lack the curiosity to dig deeper or just assume they won’t understand so they don’t try
-
that child like curiosity is too easily lost .. as a society we should encourage more of it
-
Def something I try and instill in my kids, and they both are always asking questions about how things work
-
I see Elon posted a repl from his own AI that included fake news .. says t took jury 8 hrs to convict SBF when in fact it was just 4 hours. we need to be more careful
-
Oof
-
Elon Musk (@elonmusk)
Grok has real-time access to info via the 𝕏 platform, which is a massive advantage over other models. It’s also based & loves sarcasm. I have no idea who could have guided it this way 🤷♂️ 🤣
- 11 November 2023 (1 messages)
-
Joined.
- 16 November 2023 (1 messages)
-
Joined. - 17 November 2023 (1 messages)
-
- 18 November 2023 (1 messages)
-
Thank you @B0BSmith for the heads up! Is quite the timing to release this in a Friday afternoon just before a major holiday week 🤯
But even if I’m not surprised at all, it doesn’t mean it’s not critical what is happening. So I took the time to follow up on the situation. And this time I’m only focusing on these 2 weeks given to the rest of the federated nodes to update their infrastructure.
https://github.com/CounterpartyXCP/cips/discussions/124
Reactions in this chat are appreciated, but I believe in this critical time the repo is the best place to follow up.
Please comment, because in the CURRENT master branch / already released update this will mean xcp.dev won’t be updated on time.PROTOCOL MINOR UPDATE: V9.61 · CounterpartyXCP/cips · Discussion #124Let this be the space to discuss the next protocol-changing release, a consensus hashes affecting PROTOCOL MAJOR / MINOR UPDATE. Federated node operators, separate from the develop- branch leader, ...
- 20 November 2023 (2 messages)
-
Anybody interested to see the visual infographic of Counterparty Tokens/Project/Developments/Forks from 2014 - 2021?
https://time.graphics/line/858561Counterparty Historic NFT Timeline - TimelineAll events are represented on the interactive timeline and can be visualized. You can review all the cause-and-effect relations of timeline
-
This Is great ser - 21 November 2023 (101 messages)
-
Idea for CIP - Relax rules requiring a user to have published a pubkey · CounterpartyXCP/cips · Discussion #125
Now that Counterparty mainly uses OP_RETURN it would make on boarding new users easier if the rules requiring a user to have previously published a pubkey could be relaxed A pub key is only require...
-
Does anyone here know the answer to this question?
-
What's the logic for restricting how many times a dispenser can be refilled?
If a dispenser is successful and sell out everytime why prevent it from being refilled?
A user can always create a new address and open a dispenser ..so why prevent a refill to a successful dispenser ? -
I knew dispensers were to be limited limited 1000 ... but not that refills would be limited, was only when new release dropped did I become e aware of this change
-
are there discussions on preventing dispenser refills ? perhaps this issue is the one to point at when trying g to get more decentralisation in development
-
division no discussion
That is the way of Jeremy's project -
Which I why I raise the issue here, we can hopefully point to this change in consensus without discussion as to why one person should not have so much influence/power/control
-
You cannot question his influence or control in any of his channels. This is his project and it has been since he broke the social contract by rushing a half-assed dispenser "solution"
The repeating behavior shows that he is non-negotiable. That's not something that changes overnight.
furthermore, while we're on the topic, his tone to people is not one which I would like a representative of the project I'm involved to use commonly -
we must call him out else we culpable lol
-
JPJA being made in charge of CIPs is a step in right direction .. we must make noise and push in the right direction . demand discussion etc
-
xchain censors n should not be accepted as being the source of truth for 'Counterparty'
-
i would suggest build a new block explorer if you dont like whats currently out there
-
like what juan did with xcp.dev and i did with memepool.wtf
-
I believe one of my last interactions on this level was me recommending a new ‘xchain only’ chat (publicly in the counterparty chat, directly to Jdog) to help clear the ‘official counterparty tg chat’ of mentions of xchain, and to make jdog aware of how close the entities are intertwined. IMO xchain talk from jdog should be in a xchain chat. I still don’t have a fednode running and I’m glad I havent taken the time yet with the winds constantly changing. Looking for dev docs on the surface web for a fednode is what brought me to the XCP tg community in the first place fwiw.
-
its easy to criticize, harder to build the thing that you want to see exist
-
I dont hate on jdog. I’m thankful and appreciative. It’s a tough position to be in. I hope he sees the love and support many have for him and the community. Advice is not always criticism.
-
I am not hating on JDog .. I agree with him on many things .. he has carried the project forwards too, I just want to see the best for CP
-
I will work links to memepool.wtf in to the things I am making like I have done with xcp.dev
Its very nice to have multiple Counterparty explorers .. thanks go to the builders! -
Does memepool.wtf allow dispenser purchases, or have DEX capabilities?
-
dispenser purchases are not a function of xchain
-
Sorry, im a noob when it comes to XCP at this level
-
no problem .. but this is the type of miss understanding the community needs to address by providing better education I suppose .. I do try n answer ppls questions with good infos when i can
-
the qr codes displayed on xchain are just bitcoin addreses with open dispensers .. you can obtain the info from xcp.dev too
-
perhaps memepool.wtf too I need to exp.ore that site I only just learned of it today
-
its currently just transactions and blocks
-
probly going to rebuild the framework too so it could change a lot
-
Right now, I believe, this is the place to unite: https://github.com/CounterpartyXCP/cips/discussions/124PROTOCOL MINOR UPDATE: V9.61 · CounterpartyXCP/cips · Discussion #124
Let this be the space to discuss the next protocol-changing release, a consensus hashes affecting PROTOCOL MAJOR / MINOR UPDATE. Federated node operators, separate from the develop- branch leader, ...
-
This is clearly not enough.
The ULTIMATE control is the repo. Nothing else matters if is too easy for him to force a no consensus upgrade at the official repository -
Not only again, but perpetually
-
Let's take this to the next logical step.
You don't like the way counterparty is run make your own counterparty.
I get it I see the bigger picture and as I announced to a room full of people, a year ago, I'm ready to move on from Jeremy's project, but not the ledger or the community -
Stamps indexer going public very soon. Lots of possibilities in a cross community ecosystem
-
Are you aware the current master (already published release), activating in less than 2 weeks, changes the unpacking of the issuance messages in the bitcoin tx?
-
Is that the cip where the long descriptions are no longer in the issuance table? They make a call back to the btc node? We will probably stay on an older release for stampchain to avoid issues anyway
-
I figured a fork was inevitable at some point anyhow
-
no, thats not included, its actually fixing the way the updated issuance method was deployed so that the original issuance method is still valid
-
because it broke any assets issued with callability
-
Not yet, that will be ANOTHER bigger change to the unpacking.
If your position is to not update to the current (activating in less than 2 weeks) release, I can also officially be in that position.
Im kind of already there, but having faith the current release to be canceled (as is) to not escalate things until closer to the deadline -
Are you sure it is fixing the old way of doing them? That was not clarified to me… (will reply with link)
-
yes that was the purpose of the change
-
right now you can't do any functions like lock or issue more or change description for assets that were callable
-
Issuance backwards compatibility by pataegrillo · Pull Request #1258 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
ive asked in the dev chat but you're right it doesn't appear that anything was reverted only that it will accept the new issuance IDs
-
I stopped stamping when ‘named assets’ got a bad wrap. Numbered stamps dont make much sense to me (other than being cheap) and there is little to no consensus about stamp numbers across websites currently. I believe Jdog was correct about a lot of issues re:stamps. I cant wait to see what number my stamp has when finished. I had #150, now its not a stamp at all because it has a name 😂 Stamps are still driven by XCP even if they don’t want to admit. I’ve asked for the stamps indexer a few times. At least we are able to have this conversation. I have seen many FOSS projects vaporize, at least this one has an active dev community at all.
-
Unfortunately It won’t ever have a stamp number because it’s not called xcp stamps. That doesn’t mean it’s not tradable. Bitcoin stamps from the beginning was only about requiring bitcoin only for mint. Definitely a vibrant dev community on stamps. Lots of support from the CP community as well. Growing together really.
-
Data url baby
https://bitst.art/DANKREKTbitSTARTDiscover Bitcoin Art [Counterparty / Ordinals / NFTs]
-
Technique used by @jp_janssen ~8yrs ago
https://www.xcp.dev/tx/627ae48d6b4cffb2ea734be1016dedef4cee3f8ffefaea5602dd58c696de6b74 -
I give credit to the STAMP meme, very clever and strategic not requiring XCP
-
Counterparty isn't a hard requirement here either, I just thought it was the easiest method to bootstrap. Definitely open to other options
-
You know what
-
You might be able to do stamps right now
-
Does counterwallet have a description limit?
-
There technically isn’t a limit in the protocol
-
would it just be base64 of the image in a long string?
-
Yeah id put it in as base64
-
I think that would work
-
I’m gonna try
-
Joe what are your thoughts on best/easiest method to bootstrap the actual trading layer
-
If we do it in counterparty then it’s just counterparty
-
Asset description and done
-
Tbh I think people have done this
-
lol o man this is even funnier
-
counterwallet used spendable outputs
-
op_checkmultisig
-
Bitcoin Transaction: 04d7276660cb4a630a8d73df5ae4cf94ab21c57783832c279f0e57e4c4cfc86a
Explore the full Bitcoin ecosystem with mempool.space
-
yes we come up with a scheme that overlays on numeric assets
-
then you dont need xcp either
-
so basically the stamps protocol is just a numbering scheme
-
Ahh nice don’t even need xcp to mint
-
For posterity
-
So anytime I criticize stamps please remind me that I showed mikeinspace how to do it
-
😭
-
And what IS the problem of that?
-
Is not a BIG part of the open source and open protocols to show other people how to use It?
-
Of course
-
Remember the day you sent Matt Furie FEELSGOODMAN?
-
-
There is some good details in the beginning of the stamps TG chat. With support from j-dog and Joe, otherwise it may not even exist.
-
This was 2 days after I issued CCSATOSHI too
-
All credit to you. I even brought the initial concept to you first but you refused to build it 😭 -
It has always been our intention to open source the indexer for the community. It was greatly complicated with pulling src-20 outside of counterparty. This release should help build more CP nodes and grow together imo.
-
CCSATOSHI's outputs all come from people buying 0.00001337 SATOSHICARD
Mike has some sats in there
I want to extract those to make them ordinals
There are 7800 in each one... could make for a nice collection number -
or would that completely ruin the integrity of the art?
-
Wuuuu??? 🧐
-
It's some good lore man
-
Can I share the initial DMs outlining the concept?
-
The lore is the art
-
It’s always been
-
Sure
-
To be clear it was mikes idea I just figured out how to dust off the old Counterparty tools to make it work with what we had already
-
I don’t wanna be accused of stolen valor
-
-
Check dispensers - 3rd one
-
-
-
The initial idea was through broadcasts as freewallet didn't gate those. And then have a token point at the broadcast. You definitely came up with a better (and easier) solution.
-
This is the best online community possible. Great people here.
Any thoughts on the trading of stamps? -
@B0BSmith do you still run the SAT recovery tool I have heard about?
-
I don't have it running at this time .. i think I broke it as I get a 500 error when I try to load it
-
O yeah, we have discussed this with Mike and friends in the named stamp room. I get it. I wasn’t even trying to be in a collection, the unprunable aspect is all I cared about. I wouldn’t have added the stamp prefix if I knew it wasn’t necessary. I was just highlighting the stamp number issue.
-
I’m hardly at a desktop enough to use TOR so I’ve never seen it. I am curious about that tool though.
-
What it does is scan an addresses tx history looking for spendable Counterparty bare multisig outputs .. such as those created when making long broadcasts or minting assets with long descriptions such as stamps ... it then assembled a transaction usin bitcoincore that would then spend those outputs back to yourself ... there by removing stamp data from the utxoset .. i then developed keyburn to prevent it from being removed
- 22 November 2023 (2 messages)
-
I encourage everyone to read the release notes and voice your opinions on github.
https://github.com/CounterpartyXCP/counterparty-lib/pull/12779.61.0 Release by jdogresorg · Pull Request #1277 · CounterpartyXCP/counterparty-lib9.61.0 Release Notes Bumped bitcoin core version to 25.1 (view) Adjusted DEFAULT_MULTISIG_DUST_SIZE (7800->1000) (view) Fixed issue with oracle function returning bad values (view) Fixed issue...
-
love this
- 23 November 2023 (2 messages)
-
Left. -
Joined.
- 24 November 2023 (1 messages)
-
GM. Refined post, please read! https://github.com/CounterpartyXCP/cips/discussions/124PROTOCOL MINOR UPDATE: V9.61 · CounterpartyXCP/cips · Discussion #124
Let this be the space to discuss the next protocol-changing release, a consensus hashes affecting PROTOCOL MAJOR / MINOR UPDATE. Federated node operators, separate from the develop- branch leader, ...
- 27 November 2023 (1 messages)
-
Refined again lol. The activation block is close (~500 blocks), so there is little time to speak up!
- 28 November 2023 (49 messages)
-
I am about 600 messages behind in the main XCP dev channel with unreads going back to September. What did I miss? What changes are changing consensus? Did description get shortened?
-
Left.
-
Did this take effect? Is the description field now limited to 2,000 characters? I am thinking from a BASE64 perspective that this would seriously limit the ability to include BASE64 data.
-
I believe the spec your looking for is CIP25 - Enhanced Asset Information Spec
https://github.com/CounterpartyXCP/cips/blob/master/cip-0025.md
Here is alink to an asset CIPXXV which is using the CIP25 JSON example.... demonstrates how the JSON can be setup and what fields the JSON data render to on the xchain frontend 🙂
https://xchain.io/asset/CIPXXVcips/cip-0025.md at master · CounterpartyXCP/cipsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
no thats not included in 9.61.0
-
Is description length being limited in the near future?
-
no
-
the goal was never to limit the description but only to limit the data stored in the db itself, because it essentially is just duplicating data that exists in bitcoin block dat files anyway
-
Oh I get that. Many bad decisions were made with the best of intentions. I just read through the newest CIP’s, good stuff, as long as description length doesn’t get axed.
-
even if length within the counterparty db is limited that doesnt mean description itself would be limited
-
IMO the approach considered is inelegant, is a hack.
-
ok i look forward to your proposal
-
I’m very curious on why there has been so little activity from members of this group in https://github.com/CounterpartyXCP/cips/discussions/124PROTOCOL MINOR UPDATE: V9.61 · CounterpartyXCP/cips · Discussion #124
Let this be the space to discuss the next protocol-changing release, a consensus hashes affecting PROTOCOL MAJOR / MINOR UPDATE. Federated node operators, separate from the develop- branch leader, ...
-
My comments starting from here can be considered a pre-proposal
https://github.com/CounterpartyXCP/cips/discussions/109#discussioncomment-7245038
But I’m still hands full on just trying to improve decentralization and the processesCIP31 - Enhanced File Encoding Support · CounterpartyXCP/cips · Discussion #109Counterparty currently has an issue where file data is being stored in the counterparty database, and we are unable to move forward with updates (like P2WSH) which would allow much larger transacti...
-
It’s a lot to keep up with. Siloed conversations partly on tg, part on git. Also probably not a huge priority to most. Also there are not many who understand and care. If things get a bit easier to follow in the future, I will make an effort to contribute on Git too.
-
All true. Thanks for your sincere answer.
I’m trying to move as much of the protocol affecting conversations to the public realm on GitHub.
Few care, very true -
We can all move forward in agreement, read my latest post
-
This will not require @reinamora_137 and me to be forced to upgrade without verifying on such a short amount of time (less one holiday week)
And for the public, is an improved release. No backtracking. Forward looking in agreement -
yeah it's a lot to deal with in a short amount of time. I'm confident the new repo owners will improve the release process, and we will get more stamps devs involved early on for feedback and review before it gets to the release stage.
-
At this point sine it appears no major breaking changes are being pushed for stamps it's in our best interest to move along with it even if it means no or little testing.
-
That is precisely my point, with an adjustment to the current release you won’t be forced to the upgrade. And only do after verifying.
But instead of being done in a conflicting “must-backtrack” way, is done on a forward looking way. -
I’ve learned a lot from people like @jp_janssen and @hodlencoinfield of what are the “unwritten rules” of the community.
I truly just want the best for everyone, and being direct no-bs is my way lol -
same same.
-
im confident we can develop a better more transparent process going forward
-
jdog stepping down without ragequitting was the first part of that lol
-
I was starting to feel bad, but then it was leaning into the opposite side
I truly believe my [2] proposal is the best move forward
All that is left is for the master controlling (Jeremy) to accept it -
i can't speak for shannon or JP but after the v9.61.0 update I personally dont plan on pushing any updates (critical fix patches aside) until we have a process that we can all at least accept maybe not agree with 100% but enough that we have a path to move forward
-
Ok I definitely missed something in the dev chat.
-
Let’s make this v9.61.1!
-
We can start now!
-
Glad to see he will still be active. His support and experience is needed im sure
-
juan let us please get some rest, i have 50 pepes to draw before friday
-
🤣
-
Do you think I have rested well? lol
In all seriousness, @reinamora_137 and me need not to be forced on v9.61.0. A single file configuration file is all that needs to be adjusted!
In my case, xcp.dev will not be ready for such changes, as I have a deeper integration into the protocol. I had to build my own custom api and interface to the protocol DBs for my explorer to be cost effective. The protocol’s api is extremely inefficient
All i am asking, is that if the community really appreciates having alternatives, we must give them the opportunity to be kept relevant. Not forced them to continue being centrally dependent.
Simply put, the current established release will break xcp.dev until I’m able to do the necessary upgrades and then run a full parse -
What you are saying here, I’m already there basically
-
yeah i hear ya, its not ideal for all parties but i think its best overall to proceed with current process for this update and move forward from there
-
i can accept that we disagree on that
-
You are saying changing one file is less ideal than making a complete explorer break?
-
maybe i misunderstood then
-
Ok let me try to repeat…
-
can you link me to the change?
-
hopping in the car so may not respond for 20 min or so
-
Sets a far placeholder activation block · CounterpartyXCP/counterparty-lib@a15d7a1
- to show consensus from federated node operators (https://github.com/CounterpartyXCP/cips/discussions/124) - part of @jpja process improvement proposal (https://github.com/CounterpartyXCP/counterp...
-
It shows the original activation block before Jeremy made it “2 weeks”
-
this would be the opposite of moving forward after v9.61?
-
Is not forcing the protocol change. But all the code stays. So it is moving forward, nobody breaks, and the code can be verified and be as best as it can be.
What is urgent in the proposed protocol changes? I don’t think there is anything… but let me know -
i think i voiced my opinion on this, but what i can do is comment on the github repo with my thoughts
-
I think that would be great, and please consider the position I am in with the imminent breaking of xcp.dev.
2 weeks forced single-handedly is straight hostile towards people building on top of the CORE protocol.
And that is one big misunderstanding I see, the cp-lib api is JUST an interface. The protocol IS the SQL DB, the hashes -
S a m e
- 29 November 2023 (59 messages)
-
hello all im trying to create a lightweight read only version of counterparty lib, as i understand addrindexrs is just to create the txs as you need to know about the utxos right?
-
I think Counterparty used to use a BTCDrak modified Bitcoin core with a address index ... but it wasn't kept maintained ... so now uses addrindexrs .. as counterparty Balances are address based not utxo set based
-
the utxos are needed and used when making cp txs
-
yep, thats also why counterparty didnt have segwit for a while
-
My understanding is that it has tight coupling with lib, but the extent is what I yet cannot say.
Was recently trying to run addrsindrs by itself (not through the fednode) and was not successful, want to learn more about this integration -
there was an interim period where counterparty used index-db which was from bitpay's insight block explorer
-
its been part of counterparty since day 1
-
cool
-
there've been multiple attempts to add addrindex to bitcoin core over the years
-
a lot of good convos on the github repo about it
-
im just trying to create a lightweight way to read from counterparty withoun needing 2TB of space lol
-
Add address-based index (attempt 4?) by marcinja · Pull Request #14053 · bitcoin/bitcoin
Adds index to transactions by scriptPubKey. Based off of #2802. Stores hashes of scripts (hashed using Murmurhash3, with a hash seed that is stored in the index database), along with the COutPoint ...
-
jdog told me that is used too to check opening dispensers for wallet activity too
-
thats the last attempt im aware of
-
thank you
-
im using quicknode as bitcoin node and im pretty sure they have utxo tracking also in their api methods
-
they should
-
bitcoind has -txindex
-
going to dig more on it
-
thanks
-
Electrum servers seem to be preferred way to query addresses now a days
-
ive played with fulcrum which is pretty nice and easy to use
-
The Mempool Open Source Project®
Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.
-
I got ElecRS I think it is running on Raspiblitz .. I think the local mempool.space code on raspiblitz then uses the ElecRS under the hood
-
addrindexrs is a fork of samouriwallet addrindexrs which is a fork of romanz electrs
-
forks all the way down
-
lol
-
you can know Counterparty is not utxo based for balances as you can send tokens to an addresses that has no utxos
-
i think only problem would be with opening dispensers tx
-
dispensers work on addresses with no utxos
-
then it should work
-
obviously the moment a dispense is made the address then has a utxo but to set one up you can use a empty address
-
i have now it up and working but dk if it could be onto some problems later
-
i like to think of dispensers as counterparty database artefacts ..I may be wrong in that thinking
-
I can see part of it, from a normal BTC tx to a virtual asset. The virtual part is what I don’t know if qualifies as an “artifact” (you know after Casey used the term so eloquently 😆)
-
I no idea what Casey said as I don't really follow Ord stuff
-
are dispensers better thought of a stored sql procedures ?
-
Yes in the “trigger” sense I suppose
-
Btw @B0BSmith have you tried hyper-v? I’ve been using it lately with no issues. More reliable than virtualbox in my experience
-
I haven't no ... thats MS ... i was reading up on Quebes m
n could do with reformatting my computer n re installing stuff fresh n was thinking that was prolly best way to go -
Yeah I prefer Mac as my main dev computer. But Windows as the rig!
A 64GB Mac will cost me an eye, but the upgrade of my (laptop) rig cost me $100. So running Ubuntu hyperv inside windows is great for a live mainnet dev setup -
that makes sense .. I got a 32gb machine with 2x1tb m2 ssds .. of which one gets eaten up by bitcoincore but now I got a Raspiblitz setup I may not bother with a local instance of bitcoin n can reclaim that ssd space
-
what sssd are u using in the raspiblitz?
-
SanDisk SSD plus .. its black and red 1tb .. I think was the one Raspiblitz linked to on Amazon was about $30 I think
-
-
Nice
-
I will check it
-
Nice. I had a Rpi running my mining rig in 2013
-
they are great .. I am looking forward to the 5
-
All this windows talk is scary. Thought you guys were all Linux based by now lol
-
which one?
-
Like Kali for all around desktop purposes. Alma mostly for infrastructure in my world
-
Same! I had a single
Block erupter lol -
Any ESXi admins have good luck running nodes in a VM? I try to avoid docker whenever possible.
-
why you dont like docker?
-
I’m old
-
docker is so cool and more performant also is easy to use when you dig a little on it
-
I run into problems where if I had full control like a full stack, everything would be ok but docker has historically caused me more problems than it is supposed to fix.
-
you can enter into the container and have full control
- 30 November 2023 (63 messages)
-
Joined. -
Joined. -
HI, everyone
-
Does anyone know how to send bitcoin using send-crypto npm?
I am using p2wpkh format addresses which is starting with bc1
But seems like send-crypto module only provides p2sh addresses. -
Please help me. How should I send
-
npm sounds like Node.js .. you in the wrong room
-
Are you incorporating counterparty? Tell us more.
-
I am sorry, what you mean?
-
Does the project that you are working on include provisions for the XCP Counterparty protocol?
-
No
-
How did you end up in here?
-
then why are you asking here? who has invited you to the group and why are you called like a spyware?
-
lol
-
I thought it's bitcoin developer's community
-
*group
-
A very unique developers group
-
If you don't know, it doesn't matter
-
We might
-
You know how?
-
-
-
idk why are you using a library with 130 downloads, also with a short inspection of it it calls tons of external apis, rick seems SCAM
-
if i were you i dindt use it
-
You mean send-crypto module?
-
yes
-
135 downloads
-
not public code as is calling external apis
-
Could you recommend me good one?
-
dpends what u want to do
-
I need to send btc using node.js.
-
But address for mat is segwit address
-
Which is starting from bc1
-
Initialize transaction and sign
-
Using privatekey
-
bitcoinjslib
-
Yeah, I am using bitcoinjs-lib module.
-
But not sure how should I initialize transaction using utxos
-
but please ask the question how you ended here? this is a semiprivate group
-
Oh, I just searched bitcoin developers group, and found this one
-
okey
-
Is it private team channel?
-
this is for counterparty related only
-
If so I am so sorry for sudden join
-
not private but counterparty related
-
Not exactly what you’re doing but more along what were doing in here .. https://github.com/CounterpartyXCP/cips/blob/master/cip-0015.mdcips/cip-0015.md at master · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Oh, seems cool
-
So it's CounterpartyXCP developers group?
-
yes. one of at least two
-
I prefer this one tho
-
Seems I found exact group.
-
So you might be so good at bitcoin transactions.
-
Could I possibly get some help?
-
Which wallet are you using to sign?
-
I have Segwit wallet address and privateKey (WIF)
-
Using nodejs in the server I though
-
And I need to send specified amount of bitcoin to other wallet using node.js
-
Not in the browser
-
const network = bitcoin.networks.bitcoin;
const privateKeyWIF = CRYPTO_MAIN_WALLET.bitcoin.privateKey;
const keyPair = ECPair.fromWIF(privateKeyWIF, network);
const privateKey = keyPair.privateKey;
const publicKey = keyPair.publicKey;
const { address } = bitcoin.payments.p2wpkh({
pubkey: publicKey,
});
const feeRate = 10;
const response = await axios.get(
`https://blockstream.info/api/address/${address}/utxo`
);
const utxos = response.data;
debug({ utxos });
for (const element of utxos) {
let utxo = {};
utxo.satoshis = Math.floor(Number(element.value) * 100000000);
utxo.txId = element.txid;
utxo.outputIndex = element.output_no;
totalAmountAvailable += utxo.satoshis;
inputCount += 1;
inputs.push(utxo);
}
// Add inputs to the transaction
// Create a PSBT object
const psbt = new bitcoin.Psbt({ network });
const txPromises = utxos.map((utxo) =>
axios.get(`https://blockstream.info/api/tx/${utxo.txid}`)
);
const txResponses = await Promise.all(txPromises);
const txs = txResponses.map((txResponse) => txResponse.data);
debug({ txs });
// Add inputs to the PSBT
utxos.forEach((utxo, index) => {
psbt.addInput({
hash: utxo.txid,
index: utxo.vout,
// witnessUtxo: {
// script: outputScript,
// value: utxo.value,
// },
// redeemScript: null,
// witnessScript: null,
});
});
// Add output for the recipient
psbt.addOutput({
address: addressTo,
value: Math.round(amountTo * 1e8),
});
// Calculate transaction fee
const fee = Math.round(feeRate * bitcoin.Transaction.virtualSize(psbt));
// Add change output (if any)
const changeAmount =
utxos.reduce((total, utxo) => total + utxo.value, 0) -
Math.round(amountTo * 1e8) -
fee;
if (changeAmount > 0) {
psbt.addOutput({
address: addressTo,
value: changeAmount,
});
}
// Sign the inputs with the private key
utxos.forEach((utxo, index) => {
psbt.signInput(index, privateKey);
});
// Finalize the PSBT
psbt.finalizeAllInputs();
// Build and serialize the transaction
const tx = psbt.extractTransaction();
const serializedTx = tx.toHex();
// Broadcast the transaction
const resultBroadcast = await axios.post(
'https://blockstream.info/api/tx',
serializedTx
); -
Bitcoinjslib to create the tx and sign it think is enough as you have the private key at your script level and you can create the wallet object, then you will need to broadcast your raw tx in hex to some node I think that there are a few apis that broadcast them https://github.com/Blockstream/esplora/blob/master/API.md#post-txesplora/API.md at master · Blockstream/esplora
Explorer for Bitcoin and Liquid. Contribute to Blockstream/esplora development by creating an account on GitHub.
-
This code is what I am trying now
-
I have trouble in initializing the transaction
-
Could you give me some advice for it?
-
Looks like there is some commented witness code in there, but I’m no expert in your field. Learn all you can about counterparty and come back later.
XCP Dev Chat
Public archive of Telegram messages.
- 01 Nov 2023 (2)
- 04 Nov 2023 (2)
- 05 Nov 2023 (19)
- 06 Nov 2023 (1)
- 07 Nov 2023 (11)
- 08 Nov 2023 (56)
- 11 Nov 2023 (1)
- 16 Nov 2023 (1)
- 17 Nov 2023 (1)
- 18 Nov 2023 (1)
- 20 Nov 2023 (2)
- 21 Nov 2023 (101)
- 22 Nov 2023 (2)
- 23 Nov 2023 (2)
- 24 Nov 2023 (1)
- 27 Nov 2023 (1)
- 28 Nov 2023 (49)
- 29 Nov 2023 (59)
- 30 Nov 2023 (63)