- 20 April 2023 (112 messages)
-
i almost feel like we should take the opportunity to define a framework for offloading non-consensus data from the primary counterpartydb to another db with stamps being the first implementation -
and add some type of flag to the asset table rather than just using the word STAMP to indicate the data is somewhere else
-
i think its a great idea tho
-
you could stamp via broadcast
-
big step! -
adding a flag/field to indicate if this is a stamp (bool) vs a repetative "STAMP" (string) description is prolly best n more efficient 😉 -
Good point.. will update the CIP to handle broadcasts as well.. cuz ya, can broadcast a file too
-
you could write the sha256 hash of the file in the description when that stamp bool is flipped
-
can stamp multiple files
-
but yeah.. sha256 is what I use on tokenstamps.io to determine if files are duplicates 🙂
-
prolly do similar for the hash field in stamps table
-
i also think if we’re going to go for it, then stop using base64 and just write the hex bytes directly into the description, similar to what we do with memo
-
saves 1/3 i mean
-
yeah
-
so the original file increases in size 4/3
-
when you go to base64
-
i think you just use a hex byte outside of the base64 range to flag a description as hex
-
like ff
-
with that you could remove the stamp: prefix entirely
-
would need some new flag or way to indicate "this broadcast or issuance is a stamp".... gonna have to pass "stamp:" in description/text... OR `"stamp": true` in API request and then come up with a new issuance/broadcast format with a flag to indicate if the data is a `stamp`..... the simplicity and backwards compatability of using "stamp:" going forward is appealing :)
-
yeah an extra parameter in API makes sense, something like descriptionType: text, hex, or stamp
-
default to text which is the current option
-
set to hex if you just want hex bytes but not for a file (like a hash or something) and stamp would be in hex but counterparty-lib would store it in separate db
-
you can just go backwards from 255, so leading descriptiong hexbyte FF could be for hex and FE could be for stamp
-
text range is 00 to 3F
- 21 April 2023 (1 messages)
-
Very interesting discussion!
I outlined a possible approach in the forums:
https://forums.counterparty.io/t/stamp-file-storage/6569STAMP File StorageHere’s a suggestion to how Counterparty can handle on-chain file storage better: Add a special rule that when asset description or broadcast begins with BLOB:, assume the following format; BLOB:{filename},{blob} The blob is the file’s binary data. Counterparty will then generate the sha256 hash of {blob} and save the following text to the DB; FILE:{filename},{sha256_hex_encoded} Notes: The blob (file) itself is stored inside the BTC transaction but won’t be saved to the Counterparty DB. St...
- 22 April 2023 (2 messages)
-
all opinions matter here man and we are glad you have you... just wish you showed up years ago n we all coulda saved a bunch of 7800 multisig dust 😛
- 24 April 2023 (1 messages)
- 25 April 2023 (1 messages)
- 26 April 2023 (27 messages)
-
https://xchain.io/tx/da6b5453edf080a5d575373b6ce1d656254025226c997ae8c8dd48d39ff89f33
Why sweep shows lots of zero quantities? -
Cuz cp still has issue with creating 0 quantity balance records…. Does it for order matches too…. Creates 0.00000000 xcp credit/debit records…. Was supposed to be fixed a couple years ago with this CIP…. But still have some issues with it still… bloating db with these 0 quantity records
-
cips/cip-0023.md at master · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
-
Created GitHub release to track/fix issue a while ago… just haven’t dug into it yet…. Pull requests happily accepted👍🏻
-
zero quantity records / database purge · Issue #1113 · CounterpartyXCP/counterparty-lib
Still seeing issues with 0 quantity records being created... this is bloating the database unnecessarily.
-
https://forums.counterparty.io/t/stamp-file-storage/6569/2
Here's an outline for saving file BLOBs in asset descriptions and broadcasts. The blob is saved inside the btc tx but only the hash goes to the counterparty DB.
Kinda competing to CIP26 and 27 but should be very good for STAMPs nevertheless.
If some support, I will write a formal CIP28.STAMP File StorageHere’s a suggestion to how Counterparty can handle on-chain file storage better: Add a special rule that when asset description or broadcast begins with BLOB:, assume the following format; BLOB:{filename},{blob} The blob is the file’s binary data. Counterparty will then generate the sha256 hash of {blob} and save the following text to the DB; FILE:{filename},{sha256_hex_encoded} Notes: The blob (file) itself is stored inside the BTC transaction but won’t be saved to the Counterparty DB. St...
-
why not build an svg wrapper spec, the result is still renderable in an image tag, all tooling remains backward compatible, can cram lots of metadata inside… -
There are also already standards for placing metadata inside common image formats, exif and I forget what the png standard is. But that’s also an option for providing additional information for a stamp
-
It’s a bit cumbersome for users and a great likelihood default meta data will get parsed like: title: IMG_JPEG_000000913 -
Just because we like inventing our own stuff?
-
Most users probably have no idea how to edit metadata
-
fair enough
-
a tool can stuff info into image metadata... tho I think the "stamp a JSON file with meta-data" is prolly a more standardized route than trying to embed / dig for meta data in various file formats
-
I kinda like the idea of broadcasting additional details. Benefits: can do it later without disrupting original stamp. Maybe adding “title” to older stamps using this method.
-
Broadcast from originating address making reference to the asset in question
-
If broadcaster is the same as original creator, look for past stamp reference, that’s interesting.
-
Broadcasting was going to be the original stamp method as freewallet doesn’t cap the size of broadcasts. We ended up just doing it in description for simplicity
-
For the doom game I was thinking about chunking a file across a few assets and referencing them in the STAMP
-
Original concept for stamps: broadcast with hash referenced in description: https://xchain.io/asset/ONCHAINPUNK
-
Also considering experimenting with recreating a css sprite technique but referencing an asset and coordinates
-
CSS Image Sprites
W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.
-
Here’s the source for generating the burn addresses by John for BitcoinTrustNetwork.com -
-
Always thought this was a cool concept... brainfuck actions as tokens... tokens sent to address in order of actions can build out program... not sure exactly relevant.. but cool nonetheless ... https://robmyers.org/2014/12/23/dogecode/Dogecode
dcrun -u rpcuser -w rpcpassword DCvDS9g9VUZ94MSLbWi4zWRtxHrXeEctZ3 Hello World! Cryptographic asset tokens can represent all kinds of things. Including computer programs. Introducing…: Dogeco…
-
Clever!
-
Joined.
- 27 April 2023 (8 messages)
-
first time seeing it, very cool!
-
Link
It would be interesting to introduce a new file format (wrapper) for tokenized media with ofc appropriate standardized cross-chain embedded metadata.
-
SVG is a good idea for it
-
main issue with using EXIF, XMP etc is the filesize gets larger which is an issue for STAMPS.
-
I did do a PNG arbitrary metadata embed just appending binary with [[STAMP:<compressed data>]]. Thread here:
https://twitter.com/sull/status/1644028686029422592?s=20LinkEmbedded IMG Metadata (compressed) appended to PNG binary data:
-
thanks @XCERXCP
-
NP, love to hear peoples opinions
-
https://www.xchain.io/tx/503a7d459ab64853d8fe07e7dd6b698d97bb115fa8f3a86d25c05c0fdfd31a38
https://bitcointrustnetwork.com/site?counterparty.io
pew pew pewBitcoin Trust NetworkTag, comment and earn on a site's reputation!
- 28 April 2023 (22 messages)
-
Mempool issues under heavy load · Issue #1111 · CounterpartyXCP/counterparty-lib
The Counterparty mempool is acting very strange under heavy loads and is not expiring mined transactions from the mempool. There are currently 120K+ pending mempool transactions, and the Counterpar...
-
Time to revisit this issue again I think.... mempool hasn't been updated in 3 days... restarting CP node fresh doesn't fix, mempool is just straight up not being updated / populated when under heavy mempool loads (100k+)
-
getting lots of "is xchain broken" DMs.... nope, just CP not updating mempool 😛
-
I’ve noticed it takes a bit for unconfirmed Txs to disappear from the xchain api
-
What if there was a counterparty API that just allowed you to query txids on demand
-
Checks mempool, then if it exists it’s parsed
-
xchain mempool api just proxys request direct to CP API... there is no xchain mempool database... just queries to CP API for what is in mempool... so issue is with CP
-
But CP parses everything right
-
?
-
would like to try and revisit tweaking the existing code so it updates... not updating for 3+ days seems like a pretty big/obvious issue that we should be able to fix easily... prefer to do that rather than throw out the baby with the bathwater and go with an entirely new method.... AFAIK issue is just with an update not being triggered.... not with the update itself
-
yes... CP parses all mined txs fine... only issue is when mempool load is over X, mempool seems to stop updating
-
Hmmm
-
john n i put a fix in a while ago to "fix" this issue.... cuz CP was getting CPU bound... maxing out CPU checking 150k mempool txs every second... and blowing away and re-creatting the entire mempool... we put some code in to slow that update frequency down when mempool is busy
-
but clearly that code is not working as intended 😛
-
Well it’s working in that it’s not crashing the node
-
So that’s good lol
-
just need @pataegrillo to find some time to dig into what is happening with CP mempool right now... hopefully later today... he's been busy with segwit/taproot stuf.... almost done... got the encoding and generation creation done... just need to do the CP parsing and tx signing witness data and then he should be done n free to focus on other stuff
-
Yeah ideally you never scan the same Txid more than once
-
Then you wouldn’t have to limit how often Counterparty checks
-
yeah... smarter updating would def help.. using brute force delete-everything-n-recreate method... not ideal... but it is founders method, so haven't updated yet 😛
-
DANK AUCTION HOUSE
AUCTION NIGHT
6TH MAY 2023
10PM (U.K Time)
This will be an escrowed auction, 5% buyer and seller fees apply!
Only 42 lots available
Lots filling up fast
Join Dank Auction House for deets:
https://t.me/+FLLoyBuoWSgwN2Y0Dank Auction Househttps://t.me/+FLLoyBuoWSgwN2Y0
-
hey @jdogresorg do you know if the message_index field in the block bindings is supposed to be unique? I'm getting dupes when reprocessing them using get_block from the cp api - 29 April 2023 (7 messages)
-
^ Does anyone have suggestion on this ? I'm working on a piece that replays history and trying to figure out if this means dupes need be overwritten.
-
A question better posed to @pataegrillo … not answering cuz not sure… should be unique but Javier would know better than I
-
Message index should be unique, it's generated for every database insert or update query. Which blocks indexes have those messages duplicated? -
@pataegrillo Starting block 781545 the message_index increment goes back to 9159953, which was first recorded at block 781539
-
there are 13 message indices that seem to have overlapping messages ( 9159953 - 9159965 )
-
getting it also at message_index 9160322-9160334
-
(dm)
Official Counterparty Dev Chat
Public archive of Telegram messages.
- 03 Apr 2023 (4)
- 05 Apr 2023 (5)
- 06 Apr 2023 (44)
- 07 Apr 2023 (55)
- 08 Apr 2023 (2)
- 09 Apr 2023 (2)
- 10 Apr 2023 (8)
- 11 Apr 2023 (103)
- 12 Apr 2023 (14)
- 13 Apr 2023 (3)
- 14 Apr 2023 (67)
- 15 Apr 2023 (3)
- 16 Apr 2023 (5)
- 17 Apr 2023 (6)
- 18 Apr 2023 (21)
- 19 Apr 2023 (71)
- 20 Apr 2023 (112)
- 21 Apr 2023 (1)
- 22 Apr 2023 (2)
- 24 Apr 2023 (1)
- 25 Apr 2023 (1)
- 26 Apr 2023 (27)
- 27 Apr 2023 (8)
- 28 Apr 2023 (22)
- 29 Apr 2023 (7)