- 01 February 2024 (128 messages)
-
-
yes really strange
-
This is expected lol. Haven’t updated CP for bitstart yet… -
But here the verify is now showing correctly
-
Notice that address page now shows all sections loading separately. I am currently workin on the rest of the pages to have similar behavior, no more hidden missed data that doesn’t show explicitly.
The asset page is the most dynamic so is the last one I’m working on… but should be ready in a couple of days. Finishing the transaction page today-tomorrow and then is finally the asset page -
yes now is showing good
-
but it has took more than 5 blocks
-
is runing in 9.60 bitsart
-
jajajajja
-
How many did it take? -
Maybe was 5 ser... The guy told me that was more than 5 but when he finally send me the close tx was passed just 6 blocks and was showing.... So maybe was my bad for don't double check before press the fire button... Sorry
-
Joined. -
Welcome to the reset rabbit hole 😎
The asset table has the genesis block. But before the reset, all issuances must have the same divisibility. So you could just take any valid issuance and trust is the correct divisibility.
Now if you want to treat resets like the rest, you can only trust the latest issuance, which can only be obtained with an ‘order by’. The genesis block, that can filter the query even more, is unused.
https://github.com/CounterpartyXCP/counterparty-lib/commit/5d0a0457600c9af69137af34dd7397ab4866d9a1
In xcpdev I discriminate resets lol. I don’t have an option if I want to be performant (it still affects me a bit). Genesis issuance is given relevance.
The util is even used for logs. I would remove that at least.update `is_divisible()` to use latest issuance · CounterpartyXCP/counterparty-lib@5d0a045Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
-
Thank you! 🙏 I was basically alone in that sentiment lol
Looking forward to this… after re-reading it I may be getting what you are heading towards with your name suggestion… 🔥🔥🔥
https://github.com/CounterpartyXCP/counterparty-lib/issues/1336
Issuance table has a bunch of indexes so that has other consequences… but at least that one can also be useful for latest description not only divisibility… but remember the sweep concernReplace Issuance `reset` Feature with an `Un-issue` Command · Issue #1336 · CounterpartyXCP/counterparty-libNot sure what to call it. But this is much cleaner. If we should have a reset feature, then we shouldn't force users to pick divisibility ahead of time e.g.
-
wow! and i yanked all that kickstart stuff out of the code when i ported it over to do stamps lol. I thought it was the transaction decoding from the libraries that was the slowest part (and same in my profiling) i'm surprised just pulling the trx data would be that fast - or is kickstart decoding them as well? -
The prefetcher is 😍, simple and powerful
https://github.com/CounterpartyXCP/counterparty-lib/pull/1374[WIP] Block Prefetcher by adamkrellenstein · Pull Request #1374 · CounterpartyXCP/counterparty-libI haven't done any benchmarking yet, but it's definitely faster!
-
Amazed by that time improvement will definitely be porting that over to my code for sure. I got confused by it when it wasn’t working so just yanked it lol should have spent some time fixing I guess
-
Yeah that was my baseline when creating it so I could figure out how to handle reorgs
-
Just removed all the stuff I didn’t need. We kept the arc4 encoding and everything the same for src-20 as a nod to cp
-
But basically we pull cp transactions from cp via api and also parse btc looking for src-20
-
Learned a lot from it as my first Python project
-
Definitely. I didn’t feel any code contributions in the past would have been accepted or appreciated so I kind of focused on our own stuff, but that has clearly changed.
-
Oh boy where do we start… -
an evolution rather than a planned protocol
-
Haha because spam
-
Forced off cp basically
-
an emergent protocol lol
-
To avoid a fork
-
you mean stamps and src20? they are actually one, they are both stamps to the community eyes
-
imo every indexer/metaprotocol on bitcoin should figure out how to integrate more with each other, they’re all dependent on bitcoin after all
-
Haha I mean we certainly could move src-20 back into cp.
-
i like that you guys have a hybrid protocol, good lab experiment
-
stamps could only fully integrate with counterparty if they could allow op_return into their hearts
-
Yeah was a good learning experience at least. We intended to do atomic swaps and things that we expected cp may never support but that is changing too
-
its not a misunderstanding really, its completely understood its not technically necessary
-
Yeah a precarious meme effect is all it is
-
True I mean we do have the ability to go direct to miners now without the op return limit as well
-
And no dust
-
yeah its incredible, i love seeing the big op_returns
-
Be cool to utilize those relationships we built to hook into cp as well for that op return benefit
-
It is through minting services anyway so not a big lift
-
Haha wow yeah definitely a new reality
-
We may have something closer to the Halvening to “compete” with Runes at which point we’ll have some flexibility to pivot the narrative and tech a bit. Under Stamps it’s hard because the meme (believe it or not) is important.
-
Yeah we have a new protocol basically we could incorporate and use op return
-
Instead of doing it on our own it would be a good reason to shift that back into cp
-
Even if we left src-20 as-is since we now have okx indexing those it would be major to change things back
-
countstamperparty
-
nice progress so far! at 0.36586728 sent some today as well.
-
Sharing in some inner chats 🙏 -
Just want to be clear: that was not stamps dev funds; I'm assuming you sent from the open indexer fundraise. Don't want people to get the wrong impression that funds intended for the Stamp dev fund were used for something outside of Stamps development (though I understand a case can be made that CP development does end up contributing to Stamps). Just concerned about the optics.
-
Well actually this is stamps development imo
-
But yes I understand your concerns
-
Fair, but that particular fundraise was at Kevin's discretion. It's separate from the "stamps dev fund" which I manage for the community.
-
How did your initial setup go?
I’m open to suggestions. I could use anything from an old Rpi2, NUC, 1U Linux box, local ESXi on ssd or the cloud. Let me know if we need to test a specific setup or config.
With the more basic node recently released, and seeing the general light weight idea behind towerOS; are the new (old) devs in this chat leaning away from a full stack for the protocol? Is a full stack with wallet and explorer still the intention?
What kind of server environment are we trying to suggest? -
xcpdev continues with the same plans. See https://github.com/CNTRPRTY/xcpdev-genesis/issues/17
The new counterparty-lib (which will be renamed to -core? Maybe after addressindexrs is removed?) will only benefit everyone.
I might still make some minor non-protocol affecting adjustments for the benefit of xcpdev and future plans which include the explorer incorporated into the fednode.
A FULL wallet also, eventually. The current web one is an interface to the the lib’s create calls without requiring private keys and that has its usefulness alsoSplit repo · Issue #17 · CNTRPRTY/xcpdev-genesis@JavierCervilla @Chriton @DerpHerpenstein @mkeresty I'm thinking about splitting this one repo into: CNTRPRTY/xcpdev-genesis: This repo reverted to commit 0ffba5d. Will live in its own subdomai...
-
🥹 thank you
-
Correct, from my personal funds which are sort of slushed in with funds from stamps dev 🙂 but yeah just a gesture of support from a stamps dev
-
I’ll add that *someone* from this chat… dm’d me for a BTC gift. Very grateful, now I can say I have received sats for my work 🤓
-
Bots always come by pairs...
-
If you ever get pissed at stamps being on your node you can just send it back hahaha 😂
-
I give them the benefit of the doubt… but if you’re sure they are I can also remove them. The coming in pairs is a tell 😆
-
the names, the fact they come in pairs and that i dont share any group with them, and that they are not answering any of this messages....
-
Gone 🔨
-
im getting this on a multi send... can anyone assist
Error validating transaction: Error running script for input 0 referencing 6f13dfeb033cf293980e2a75190781891a192705712956428b24a0afdb3cd238 at 0: scriptsig not push only for P2SH. -
Hey you made it to this chat too. Welcome. I remember the fateful day well, I hope things are turning around for you.
-
What wallet/service?
-
they are not... but that is a problem i will shoulder
Thank you for asking
Right now i am just trying to do a multi send and i cannot -
freewallet
-
I see you posted this to other channels. Lets try to get you help there. This chat is more for developing/fixing the protocol and it looks like you have some good friends working on it already.
- 02 February 2024 (26 messages)
-
ok thanks
-
That was quick! Nice to see
-
Don’t miss this awesome thread by @B0BSmith and can we bring this topic back here or to git instead of the dumpster fire public dev tech support chat? This is great stuff Bob. You can dm me about this topic again. https://t.me/Counterparty_Dev/11567B0B Smith in Official Counterparty Dev Chat
any devs care to comment ? Why are users getting a error when trying to do a multisend? l don't recall this error being a issue when mempool was empty and 1 sat byte txs were the norm
-
mononaut posted this hash on Twitter mempool.space/tx/94e319d09fc236fb9d7a24e60af8f47ed41ca3cc01e9950c925d806153ed8aa3 showing a jpg inserted 7 years ago using OP_RETURN.
this has his not showing as having data on XCP.dev and bitst.art
what technique did this person use to upload the jpg, and how is this different from the current techniques we use? I take it that this method is not as efficient? Is there something useful in this tx that can be considered/adopted?Bitcoin Transaction: 94e319d09fc236fb9d7a24e60af8f47ed41ca3cc01e9950c925d806153ed8aa3Explore the full Bitcoin ecosystem with mempool.space
-
Is it just a pointer? I see mr-burns.jpg
-
-
-
😂 the output from the output from above.
-
My kind of tester.
-
@krostue can you share the tweet for more info?
-
The opreturn is small, so if the image is on chain it seems to be in the inputs. Is the image viewable somewhere?
-
mononaut (🥪/acc) (@mononautical) on X
Extract this jpeg from your own Bitcoin node! https://t.co/q6jl07S9zg
-
Nice!
-
Fake inputs? That’s possible?
-
mpma uses a op_return in the second tx but puts data into the outputs of the first tx that then become the inputs of the second -
FYI The stampchain CP node mempool is 16gb to help make sure stamps don’t fall out since sometimes they can take weeks
-
also. my message hash is not matching coindaddy.io or counterparty.io, but it is matching xcp.dev right now.. i just did a full reparse on both nodes last week....
-
Message hashes change if the node has seen a reorg so not too surprising
-
Although going forward without the undolog that won’t happen
-
cool thx just checking. i think i recall some previous notes on that and JA reminded me 🙂 I'm setting up some automated validations between all of them to ensure our indexing on top of CP stays consistent
-
is coindaddy and counterparty urls pointing to different servers?
-
Does the api have a call that returns the version of counterparty it is running?
-
The get_running_info method
- 03 February 2024 (40 messages)
-
Found a bug in xcpdev which was causing sometimes seeing weird / missing data. Have seen some mentions here and have also received DMs.
An old misconfiguration in my v9.60 infra was causing it. Should be fixed now and the code has been improved to avoid it in the future. -
xcp.dev has been updated!
Now errors in data loading will show explicitly in all pages (let me know if you find something left). In most cases, refreshing the page will solve them.
What happens is just the website reaching a limit of retries for the data to be cached. If you wait too long the cache gets lost so try to refresh quickly when the errors show.
Why show errors? The infrastructure is small to keep costs down. Found this to be better than showing incomplete data without warning.
This is the first step, eventually these errors should be minimized as much as possible. -
Still doing the CP on my node setup using xcp dev repo... -
just trying to understand as I have yet to look at the code... the sych now is basically looking at all the BTC data and populating the DB and that is why it is so slow as it goes block by block?
-
my main goal is just to get a node up and running and if switching to the "core" would help with testing let me know, running an AWS instance and happy to nuke this and test bringing another build up, this is just for me to get used to the code and setup so happy to nuke as things change, let me know if this would be helpful
-
because I'm from Windows I'm ramping up on building on ubuntu, is there a doc that has the steps to install "core" from develop?
-
the xcp dev is a docker
-
I have build and installed ORD on machines but that might be easier
-
like compiled the code
-
is this up accurate
-
Documentation/Installation/federated_node.md at master · CounterpartyXCP/Documentation
Official Documentation of the Counterparty Project - CounterpartyXCP/Documentation
-
I do think that having simple instructions to help dev gets nodes up would be helpful, I get the concern that this is basic stuff for most and you do not want to end up just running a help desk for people to get stuff running but do not understand it
-
I will be doing all of this on Ubuntu as that seems to be the best OS for this in prod
-
I might also try and see if I can get a dev setup on OSX
-
Just curious, desktop gui or server cli flavor?
-
CentOS worked for me and it’s not to complicated to secure -
Joined.
-
Is there an issue with mult-sends right now? I saw discussion in the freewallet TG stating it was a protocol issue? -
Desktop locally, Server on AWS
-
I think I might keep going with xcp dev build as I'm over a week in, but happy to nuke and test something else once a milestone is hit, let me know
- 05 February 2024 (12 messages)
-
Anyone going to NFT Paris Feb 23-25?
A counterparty (dev) side event would be awesome. -
No to Paris, Nashville is a definite maybe.
-
Party at my place kek -
👀
-
We should seriously consider planning a get together in TN
-
I know some places. It would be an honor to meet you guys!
-
The BTC Mag gallery in chestnut hill is incredible
-
Plus awesome pizza at Diceys next door 😎 🍕
-
what is TN
-
The great state of Tennessee
-
that is what I thought is there an even there?
-
Bitcoin 2024 is taking place here in Nashville
- 06 February 2024 (17 messages)
-
A meetup would be cool
-
we are open to help to organize this
-
@uanbtc @teysol If you guys want one of these, shoot me your xcp address. Token of appreciation for you work. https://xchain.io/asset/XCPMAG
-
Thank you!! Will DM
- 08 February 2024 (9 messages)
-
Hey frens, is rarepepewallet.wtf open source?
-
no, but all wallet code is in the client if you want to view it locally
-
keep in mind that any other open source counterparty wallet that uses an API to construct txs is implicitly blind signing a tx sent from the server, rarepepewallet.com and rarepepewallet.wtf construct txs locally so you can follow the logic if you’re so inclined
-
also counterparty-hw which is like the pre-alpha version of rarepepewallet.wtf IS open source, anyone can build anything from that if they’d like its MIT license
-
GitHub - loon3/counterparty-hw: Counterparty wallet for use with Ledger Nano S / S Plus / X
Counterparty wallet for use with Ledger Nano S / S Plus / X - GitHub - loon3/counterparty-hw: Counterparty wallet for use with Ledger Nano S / S Plus / X
-
this way if rpw disappears and you’re storing assets on a ledger you still have access to them
-
Thank you ser Looney 🫡 feels SAFU man
-
was reading https://rodarmor.com/blog/runes/ the other day and its not too different from how we discussed adding utxo-binding of assets in counterparty (to enable psbts, etc.)
-
“On the other hand, the world of fungible tokens is a near totally irredeemable pit of deceit and avarice, so it might be a wash.”
Good read. It is very interesting how all around the world there are people working on similar problems in parallel. - 09 February 2024 (12 messages)
-
"I'm not sure creating a new fungible token protocol for Bitcoin is a good idea. Fungible tokens are 99.9% scams and memes. However, they don't appear to be going away any time soon, similar to the way in which casinos don't appear to be going away any time soon."
Such a horrible bias. Lets us not forget that LACK OF fungibility is a problem that Counterparty solved for collectibles.
Cardboard trading cards need condition reports. Two cards of the same kind can have very different valuations.
Counterparty tokens, in contrast, remain forever in mint condition. -
The Bullish Case for Ordinals with Pete Rizzo - WBD764
Listen to this episode from What Bitcoin Did with Peter McCormack on Spotify. Pete Rizzo is the editor of Bitcoin Magazine, and one of Bitcoin’s leading journalists. In this interview, we discuss the role of Ordinals, Inscriptions and BRC20 tokens, whether they are a positive or negative for Bitcoin and the growing divide in Bitcoin culture. - Show notes: https://www.whatbitcoindid.com/podcast/the-bullish-case-for-ordinals This episode’s sponsors: Iris Energy - Bitcoin Mining. Done Sustainably Bitcasino - The Future of Gaming is here Ledger - State of the art Bitcoin hardware wallet Wasabi Wallet - Privacy by default Unchained - Secure your bitcoin with confidence Bitcoin Atlantis - A Bitcoin conference in the Atlantic SwanBitcoin - Invest in Bitcoin with Swan
-
Rizzo makes some of the best arguments for tokens on Bitcoin
-
Some history there?
-
His opinion has def changed then
- 10 February 2024 (40 messages)
-
hello, i have writted a new cip, this one intention is to create a way to lock description and ensure inmutability, please take a look when you have the time for it :) https://github.com/CounterpartyXCP/cips/pull/136feat(CIP0034):[DRAFT] First draft of CIP-0034 (Lock Description) by JavierCervilla · Pull Request #136 · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
this is my first CIP so please let me know what can improve on it and i will do
-
CIP Editor yes. I will review it after the weekend.
-
I believe the process is to formalize the CIP after discussion reaches agreement. There's really no need for such nonsense to be a part of the protocol. If you really want to sabotage yourself from ever being able to update any information then simply throw your ownership in any one of the plethora of burn addresses available
-
Is optional anyway
-
I added a link to discussion on the PR
-
But I'm interested in know why you call it nonsense
-
issuances need an overhaul anyway, might as well just add this to the list
-
Lockable description has been suggested several times before. It is certainly a feature (parts of) the community would like.
I'm happy we'll finally have a formal cip @XJA77. -
Idk if is well wrote so any changes needed really happy to do it
-
Yeah the big benefit of retaining ownership without having to send to a burn address is great. Even allows for ownership transfer where the creator can be assured it won’t be altered later. I think ownership transfer has a lot of value and should be looked at as a potential way to sell the issuance regardless of supply.
-
Kind of like selling the original piece of art instead of a bunch of prints really
-
Not to mention it allows the purchaser of the issuance to create subassets for more value creation
-
May be a downside lol. Perhaps a lock subassets from being created as an option in that rabbit hole
-
Sending to burn address can be that option.
Locking the description is included in this suggested new issuances schema: https://github.com/CounterpartyXCP/cips/discussions/109#discussioncomment-7245038CIP31 - 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...
-
But if you send it to burn there are any other things you loose
-
Adding lock_subassets? Not sure if I like the idea just thinking out loud
-
I am very happy this is being discussed, it's been wanted by the community for a very long time as a "optional" feature ❤️ -
You could use that same argument for locking supply. The point is to prove it to the user/buyer that you CAN’T make an update. Throwing your key away proves nothing as you can’t prove you actually did that
-
Oh I missed the burn address part. But even that is wonky… which burn address? Now a human has to scrutinize the validity of the burn address
-
you could always use counterparty burn address if you needed one
-
Yeah you could codify a specific burn address, I was responding to the argument to use "one of a plethora" of burn addresses.
-
But why do we even have a destruction command in CP? All it did was replace sending to a burn address
-
destroy was a function that existed from the start, then was disabled, then was reenabled
-
but yeah if we accept burn addresses exist then there’s no reason for destroy
-
would be nice to be able to issue assets that can’t be destroyed
-
only burned
-
Unlock too?
-
but it would disable you to mint subassets
-
or (in theory) issue more supply if token is unlocked
-
I’m glad this topic has come up. I understand the technical ‘what is happening’ with keyburn, but I did not come to counterparty for memes, and I’m a bit lost about the ‘why’ to the whole key burning thing. How would keyburn or description lock be useful in the intended initial use cases of counterparty?
-
now THATS an interesting idea!
-
Remember the recall function. 😂
-
This has nothing to do with KeyBurn or memes.
-
Lock description · CounterpartyXCP/cips · Discussion #135
This space is to discuss implementation of a lock description operation to ensure inmutability of assets
- 11 February 2024 (97 messages)
-
As an artist a hard realization for me to come to terms with is that once artwork is released into the world, anything can be made of it. If someone buys a painting of a beautiful lady and adds a mustache, that is up to them. (Cultural antiquities maybe the exception)
If the painter does not want a mustache added to their beautiful lady then they should sell to a buyer who respects their artwork, or better yet... if the artist does not want to relinquish control, then they should not part with it in the first place.
I'm going to take this to the extreme because that is where I see it going quickly after enabling this "useful option" as a protocol change.
Removing the right to repair assets will become a prerequisite for affluencer copycat projects. This will kneecap full use of this platform and create wasted assets that did not make the cut.
It is also very ignorant for people to weigh in on this topic unless they can comprehend the concepts of link rot or deprecation of data formats over time. Especially in the context of making things that are supposed to last forever, where the terms of ownership are more defined by curation by the chain of custody than first sale and second owner. -
I understand your worries about broken links but is up to you to dont lock the description if you don't want to lock it or lock it if you want to do it
-
this is the sticky bit:
Just because an idea sounds good to the author does not mean it will work for most people in most areas where Counterparty is used.
As it seems that proponents of this draft think only of their use-case and not the consequences of introducing this from multiple other viewpoints. -
Ser what changes for you if you don't want to lock it?
-
You don't have to do anything and is in the same state as now
-
But if you want to do it you can
-
I have addressed my concerns in a thoughtful way. I am not interested in responding to your repetition
-
Is up to you use it or not
-
"up to you" is really faulty ground to stand on, imho
-
Lol is the decision of the artist to use that feature or not same as the decision to lock issuance or not
-
I think the very idea of relying on hard-coded links is a bad idea. Yes they are susceptible to link rot. A hash might be the best solution and leave it up to tools outside the protocol to link to the artwork based on the hash.
Here’s another consideration: with Rare Pepe most of the description links either don’t work or are missing entirely. I think it would be defacement to update those links at this point. They resolve fine based on social consensus. The broken links are almost part of the art just like a sculpture like Venus de Milo having broken arms. -
Blockchain immutability (limitations and all) are sort of the whole point of NFTs.
-
If someone were to update the description field of the Nakamoto card today to make it resolve, I think that could only hurt its value, it’s a relic that should be preserved
-
they are the first/biggest institutionalized publication process. They did the great service of linking the image to the token. However, many projects alike do a great disservice to users by discouraging them from understanding the usefulness and teaching them how to utilized the standards proposed and used on a protocol level.
linking the metadata to the token is not a set-it and forget it kind of thing.
many people lose sight of the balance of immutability and the very real need to make updates and changes when trying to wrap their brain around the multifaceted nature of this tech. imposing the ignorance on others is very distasteful. -
if we scale that to each token and made by each user, then why even use the Blockchain for metadata links?
-
Anyway with this feature implemented asset owner require to create a new issuance locking the description, is not an automatic process
-
but it is up to Mike (token issuance owner) to decide is the point
-
Kinda. If Mike decided to update the description to point to some random image instead, would that be accepted by the community? There is clear social consensus as to what the Nakamoto card is “supposed” to look like. I won’t even get into “green banner” stuff.
-
which only gives more reason for the option to lock to be a feature
-
what if he doesnt lock and it gets compromised by someone that might do that?
-
I’m for this feature 😁
-
samezies
-
Yeah I’m just ruminating philosophically
-
I think part of the “mess” if you want to call it that is there has never been a specified method of using a pointer and/or hash so we ended up with a hodge-podge of methods including json (which I really hate).
I always felt the tooling should have done a better job at generating a hash and including it in the description in some standardized way, so if the pointer ever broke, there was some “fallback”. -
which eventually led to JPJA, Cornholio etc experiments.....
im not sure how this would look but i like the idea -
Experiments are great. Standardization is really important tho. Something for everyone to follow.
-
but freedom to choose how you would like to describe your asset is also important - even if a function was added internally to 'hash' the data imo it would still have to be somewhat optional
-
again, just my opinion
-
Anyone could run a version of counterparty with description locking on top of the current version
-
Yes of course, you should have the freedom. I think a lot of users would prefer standardization enforced at the software level.
-
depends on what it is and if the 'standardization' was formed with consensus..... i mean case and point with trying to develop an agreed upon way to reference data is CIP25.... which was very very contested for many reasons from what I read.... and hard to find consensus on how to organize all the types of data in descriptions
-
Yep this is the propossal, a field in the issuance itself that by default is false so if you want you can issue it with it and ensure your data is inmutable
-
God, don’t remind me. Had I just traded 1 BTC in the original crowd sale, I think the conversion was 2,000 ETH… and Bitcoin was only $500.
-
Eey Duncan, talking your first paragraph and example It would be an illigal action in most of the countries in the world making a change if the artist decide that he dont want any changes on the artwork.
So having an option for the artist and also collectors to lock the art its a great utillity that can allow artworks to convert with current regulations if the artist want to do so.
I dont see how this "optional" features can be bad in any means.
I agree with you that locking the description of a hardcoded link It would be a very bad idea. But from a collectors POV Will be something to consider as buying a asset where the supply IS not locked. Yet buying assets with locked supply its recommended.
https://www.theartnewspaper.com/2022/01/28/site-specific-art-unprotected-under-us-lawUnlike paintings and sculptures, site-specific art lacks protection under US lawRecent disputes over the dismantling, relocation or recontextualizing of site-specific works have underlined the limited protections for such art
-
-
In my POV this approach Will be a great feature for onchain art and a bad one for artworks pointing to any other links.
-
I understand that your concerns could come if an artist of an existing collection with links to the media could lock It making It imposible to repair in the future. But the artist could also in this case change the description to the emoji of a shit.
At the end of the day this feature enable a new layer of decentralization to the artowkork to artist and collectors. And being optional just make It something good in every POV. -
off topic, my node is at 690k, will be great once we have a new build so a node can get up and running within days and not weeks.
-
Would description lock remove other peoples reasoning for key burn?
-
KeyBurn (if we’re talking about the same thing — I’m not sure) has nothing to do with the lock feature. Maybe you need to better articulate what’s you’re asking.
-
the bandwagon mentality is what helped usher in many of the buggy features that riddles(ed) this project.
there should be no problem exploring concerns that are outside of the viewpoint of the author or advocate for any proposed "improvement"
if we want to claim consensus, we need to examine all possible arguments and come to terms with them.
As @hodlencoinfield pointed out, nothing is stopping you from running your own node and providing that service to people on your own version. There is no hard reason that this needs to be implemented in order to achieve full functionality for the whole system
the worse part is that this project should not be directed by the whims of people who have a very narrow way of using the tech based entirely upon "muh gains." There is a definite balance between what is wanted and needed in order to best serve everyone involved currently, but also in the future -
and, this is like the bottom of the list of important things that need to be done. I'm not personally attached to this idea one way or another. Just voicing reasoning that is beyond those tho blindly agree without trying to fully examine the issue from all angles.
it is no doubt up to the community which way this goes. I am not trying to state these things "in order to get my way" I am attempting to round out the discussion. As I feel at least a few people understand the opposing narrative, I will discontinue feeding it -
I have no personal attachment with misguided criticism of my persona due to the claimants inability to entertain ideas other than their own
-
I'm also putting myself into time out. not gonna add anything more to this topic. sorry for the ruffled feathers
-
@hodlencoinfield - inscribe.art pulls inscription data rather than an ordinal with an inscription, right? So there is no concern of having a sat reinscribed and changing its results or am I misunderstanding the set up? -
An artist can lock a description with a json link and then change the image on the site they control.
-
EDS recently amended FDCARD and SATOSHICARD's descriptions with pointers to inscriptions, which I think is a good thing. I've seen RAREPEPE holders wish that Mike would do the same.
-
Yes it references a specific inscription reveal Tx, essentially using the txid as the link to whatever data is stored in the witness of that Tx, nothing to do with sat ids
-
There’s a sort of obsession with people wanting to inscribe rare pepe images, when rare pepes by simply existing without any link demonstrate how unnecessary that really is
-
Wait till big Ordinals money realizes XCP was here all along kek
-
Eh, it’ll be the next wave that wants something “different” on bitcoin that rediscovers counterparty
-
They will buy our Pepes at a premium kek. Not that im selling 😏
-
Hello guys, can we help a guy that has been scammed(compromised pkey) to performa sweep in their wallet to save his assets?
-
I have never done a sweep so I don't know all the details
-
But if someone is available we can try to help him
-
does anyone has performed a sweep here?
-
im getting this error
-
-
yes this could work
-
yes i know...
-
thanks derp
-
FYI, xcp.dev apis are down because they can’t connect to some internal servers. Seems to be an issue with AWS because I can’t access neither v9.60 and v9.61, but I can to a newer server I had… will wait for a bit before taking further actions
-
Follow up, not an issue with AWS. Is with bitcoin core… interesting that both nodes got it at the same time…
-
I had a similar problem with the eni interface on lambda puking on connecting internally.
-
But glad you found it was core 🙂
-
Changing to a new version of the function with no other changes reinitiated the network connection interface anyway - seems similar since mine happened around the same time
-
I think mine is working good
-
But I'm not in the last version of Bitcoin core
-
And I'm running locally
-
Could be there the issue yes
- 12 February 2024 (195 messages)
-
I might have your solution. Im jumping to bed now, in 8hr i will post more.
-
We have achieved
-
Saved all the assets that still was there
-
But yes please share it when you can, will be really useful know this info
-
And have more tools as I was a little blinded
-
Yes ser i helped him to export pkey add to freewallet buy xcp and sweep the wallet
-
Through freewallet
-
Was not easy as the guy was not very familiar with counterparty but we make it
-
And I had never done a sweep before
-
Yes BTC an ordinals
-
Idk exactly
-
Couple hundreds I think
-
And the ordinals
-
And src20
-
Yes...
-
He lost an anime and some others
-
But most of the early ones was safe
-
Yes
-
People thinks is a password...
-
Can we please leave the wojack posts in the other chats?
-
The hacker had the private key and a bot that immediately sweeps btc right?
But the hacker is not aware of counterparty assets, right?
The solution is a bit complex. I will write it in details once on the desktop.
But in short you must send a very small utxo to tge addres. Needs to be so small it is not worth taking for the hacker.
You need to import the address to electrum. In the same wallet you need another address with a larger utxo. The utxo of the address you'll sweep needs to be first alphabetically (electrum sorts that way, and counterparty only looks at first input)
To make the sweep opreturn, use https://jpja.github.io/Electrum-Counterparty/sweep.html
And make sure you have some xcp to pay the sweep fee.
I recommend you try with testnet first. sweep.html?network=testnet -
so cool!
-
thanks @jp_janssen we yesterday played to the mouse and cat as we sent the xcp first so the hackers didnt notice the receipt and then we sent a small btc to compromissed address and with it unconfirmed perfomed the sweep with that utxo and very high gas
-
Successfully yes?
-
yes!
-
hopefully yes
-
Happy it seemed to work!
May i ask how the address became compromised in the first place? -
he entered the pkey in a fake page
-
I'm planning on create a script to attack his recollection input
-
"This proposal suggests adding a new field to the issuances table to lock the description of assets, ensuring the immutability of the asset descriptions."
I don't think this is correct. Descriptions are immutable. Locking descriptions will prevent NEW descriptions from being added. But the ledger of descriptions is immutable.
I don't know how to phrase this better, @mikeinspace ? -
But I don't have a good VPN for this
-
Yeah that’s true. Description updates are “appends”. With Stamps we just ignore updates. That being said, I’m not gonna get into the technicals as to why this would be needed, but I assume it would simplify indexing, if there is an assumption that the description can’t be updated.
-
It seems like counterparty description locking is more of a request from the stamps marketing department to make stamps better.
-
At the moment
-
MAKE STAMPS GREAT AGAIN
-
Let's say you're right: so what? How does an optional feature impact those who don't want to use it? That being said, I think the benefits extend beyond Stamps.
-
Periwig check your dm
-
One concern might be blurring of the line between token and asset ownership.
If the latter is locked from performing any action, it effectively becomes a static token.
How does that influence PEPENOPOULUS for example. Someone paid $3.6M for the 1/1 token. What if there's suddenly a second "token"? -
Can you elaborate? I'm not following
-
The asset ownership is transferable, ie collectable. In its current form more like a contract ownership in eth terms.
If you lock all actions, it becomes static, ie a token. If counterparty gets, psbt and it can even be traded. -
Cornholio the Great 🧻 in Counterparty Developers
An artist can lock a description with a json link and then change the image on the site they control.
-
For the record, im not necessarily against licked descriptions. Just want to carefully weigh all pros and cons.
-
Me either
-
By using hashes both in the description and inside the json, it can be done immutably.
-
Correct, people collecting locked asset ownerships might become an unintended consequence.
-
Asset ownership is different from description, I think
-
Hmmm… things tended to just get implemented unilaterally these last few years.
-
The asset ownership gives the right to add a new description.
But the asset ownership is also transferable. Jdog even built coindaddy, a marketplace for trading these.
It's a matter of perception what to make of these. People do collect namecoin domains and ENS and several historic name registries on ethereum.
Making descriptions lockable on counterparty might spur interest in a new class of collectibles. Whether that's good or bad.. -
Yes, and because it's transferable it's sort of a master token .. separate from the issued tokens.
-
Not sure.
I will go offline now for a few hours.
@c0rnh0li0 you collected the ownership of a pepe. Would be interesting to hear your thoughts. -
I'm in favor of having the ability to lock new descriptions. I'd like to see the ability to trade asset ownership become trustless too. It would create interesting market dynamics similar to having token issuance locked or not. I imagine more people would be willing to trade their asset ownership if they could lock the description. The ability to create subassets or simply collecting an asset might be enough to drive the secondary market. I think most artists would be reluctant to trade away ownership, knowing someone can alter its metadata. However, collectors might also want the ability to do so, so having it unlocked might carry a premium. I could see it becoming the norm for new collections, which would likely lead to some unforeseen issues.
The alternative is to transfer the ownership to a burn address, and I think that is generally a bad idea. If this is simple enough to implement, I think it would be nice to have the feature added. -
I was originally in favor of the feature, but now I’m leaning into the opposite direction. Mainly because if it ain’t broken, why “fix” it?
This comment made me realize things: https://github.com/CounterpartyXCP/cips/discussions/135#discussioncomment-8431385
Descriptions are always immutable. New descriptions are appended, not replaced.
And none are considering that invalid issuances can always be used to continue adding “associated” metadata to an asset. And this can be done by anyone. xcp.dev will always show invalid issuances (it’s part of the protocol data).
If the schema of issuances is changed, then it would be possible to not insert invalid issuances. That will change the story and my option might change again. Because this will mean that descriptions are no longer automatically copied by the protocol. Which is problematic for long descriptions + sweeps.
I would fix this and other things like the reset and backward compatibility with the original issuance data packing (with callability fields) before adding anything new.Lock description · CounterpartyXCP/cips · Discussion #135This space is to discuss implementation of a lock description operation to ensure inmutability of assets
-
If you mean issuance quantities, yea these are added, not replaced. And is consistent with what I am saying
-
Those are insightful comments, especially pertaining to the undermining of historical assets.
-
I think this would evolve into 0 issuance becoming a standard with the asset ownership becoming the 1/1 NFT.
-
It’s a strange dynamic between the asset and its tokens. I’ve recommended in the past that buyers of 1/1 pieces should demand asset ownership, but there are different interpretations as to what it exactly represents.
-
I still find it concerning that a token of RAREPEPE’s significance could be compromised and updated to something like “Nazis are the best”
-
Oof
-
If issuer privileges (ownership) can be sold through the protocol, like an “issuer transfer dispenser”, then this would be the definite “token” to own.
-
Ordinals don’t have such distinction. You “own” the sat, you can “reinscribe” it.
Not that I am a fan of this sat tracking but it “works” if everyone plays the same game -
i remember being suprised the first time i locked an asset that the description was not also locked
-
Very common. Everyone assumes this
-
i bet if you polled people they would probly think that it does not knowing
-
transferring ownership to burn address is also a fun way to not only lock description but lock ownership
-
so even if locking description was an option there would still be a reason to transfer ownership to burn address
-
It’s also ritualistic which is nice
-
I feel like I should burn sage before doing these action
-
Thankfully you left POWH out in the wild
-
any change to lock ownership would be a consensus update, but i would support adding that to any sort of planned consensus update if we’re going to lock description
-
its a counterparty solution 😆️️️️
-
conservatism was a huge part of it
-
thats why theres no evm
-
it was built but never deployed
-
no one cares about the test suite
-
obvi they should but the avg user does not know to care
-
probly not a safe presumption lol
XCP Dev Chat
Public archive of Telegram messages.
- 01 Feb 2024 (128)
- 02 Feb 2024 (26)
- 03 Feb 2024 (40)
- 05 Feb 2024 (12)
- 06 Feb 2024 (17)
- 08 Feb 2024 (9)
- 09 Feb 2024 (12)
- 10 Feb 2024 (40)
- 11 Feb 2024 (97)
- 12 Feb 2024 (195)
- 13 Feb 2024 (9)
- 18 Feb 2024 (6)
- 19 Feb 2024 (38)
- 20 Feb 2024 (15)
- 21 Feb 2024 (117)
- 22 Feb 2024 (60)
- 23 Feb 2024 (34)
- 24 Feb 2024 (74)
- 25 Feb 2024 (122)
- 26 Feb 2024 (783)
- 27 Feb 2024 (447)
- 28 Feb 2024 (108)
- 29 Feb 2024 (64)