- 14 January 2024 (319 messages)
-
$bag is a fractionalised (on ETH) rarepepe collection that lacks a RAREPEPE -
We are collection #4 is you check Pepe.wtf right now (reality position is like #16/17) -
OK well let's call it a testnet donation auction collection then
I thought auctioning off cards was being seen as a good idea to help fund some stuffs ..maybe the honeypot name is the problem? -
For my stuff It’s intentionally named that way so as to poke fun and meme on the state of the crypto markets but yeh might want to brand that thing diffeeently here :)
-
OK am open to calling it whatever i am just throwing idea out there .. I am happy donating cards to a auction collection specifically for a testnet xcp.dev instance
-
I liked the name as if we get em hooked on testnet then hopefully we entrap devs to do something
-
is rest api with GET faster than POST?
-
it has to be as the query has already been done right?
-
or is the query qhen using rest just constructed via url string data ? as opposed to json that's posted?
-
OK so they equally Performant .. got it
-
thank you for clarifying this for me
-
I was hesitant to build a load of post thinking get was quicker
-
good news! literally just fetching the block from bitcoind is a significant chunk of the block parsing time. we can get rid of that completely be fetching them in a separate thread
-
Super appreciative, just know I will try to keep it low key and not directly engage (much) with the messaging around whatever funds you want to contribute.
TLDR I don’t think I will ever ask directly like is seen too much around. People can find my addresses -
Small edit
-
That's huge improvement ser @teysol thanks a million for take your time on this -
That's a big part if we can remove the bootstrap needs is a very big improve
-
so with async detection n multi threading block read time is reduced massively for the Counterparty-lib to receive the info ... and the method used petertodd v bitcoind becomes kinda academic .. very nice!
-
I find it all fascinating
-
This where I think PeterTods lib may be faster ? .. it just seems to load blocks quicker
-
very cool tool didnt know it was looking for a profiling tool like this some time ago, py-spy cool thanks for sharing
-
-
til ty .. I just tried it and was blown away how much quicker it is
-
was 9 years ago I discovered this .. on a rasberry pi2
-
op return was all the rage in them days
-
as in it was fashionable .. coloured coins were launched n explorers showing up
-
yeah that too looked interesting
-
Peter Todd knew his stuff so I looked at his repo
-
The OP_Return Wars of 2014 – Dapps Vs Bitcoin Transactions
Abstract: In this piece we explore why Dapps are typically built on Ethereum rather than Bitcoin, which takes us all the way back to March 2014. We examine a debate about whether and how a Dapp pro…
-
I was sure I heard miners were using it and they got to be the fastest right ?
-
WOW
-
Is Ouziel here?
-
I don't want to comment on the issue and contaminate with not technical things but maybe I write an aknowledgement comment there
-
A challenge indeed! Is a good amount of time, so I don’t have any suggestions is ok!
-
I don't see it like that at all.
the previous message was something that was implicit afaik. glad for it to be explicit.
btw many of you have titles in this room now, and adminship for some who should have it.
If anyone who is actively working to help restore counterparty on GitHub or are interested in users (who are here reading silently) contacting them, please let me know via PM or here that you would like the "dev" title added.
Also, on this topic. As stated, there is no room for advertising/project pushing in this room. yet, I believe it "fair use" and a good concession, to utilize the title for recognition. If you are a STAMPS dev, or would like another word next to dev title, I would be happy to add that. (reminds me of signatures on bct) -
None
- 15 January 2024 (104 messages)
-
Me wondering what chiefsamyaza’s title will be lol. On a serious note it’s very inspiring to see all the buzz in here. Makes it very inspiring to contribute to CP! Looking forward to getting back from a quick vacation to dive into some of the work already progressing! Nice work guys -
mmmm dont uderstand this... so if i triggerrollback 824000 it takes a reparse just until that block and nothing more?
-
i thought it will trigger the reparse until that block and clean db after it and start parsing blocks again...
-
i dont understand why are there 2 commands that does the same?
-
😅
-
maybe im doing something wrong idk
-
ahhh i see so after triggering the rollback i have to start the parsing manually...
-
cool at least understanded maybe is cool add there a autostart flag for start parsing again after rollback
-
i had to do rollback again... with 824000 i cannot check anything as i lost matching hashes with xcp dev at 819576 so i will do it again from 819000
-
I suggest @xcpdesk. It has the list published regularly and the custodian of that list, @Niftyboss1, is an admin of this room created by @rarepepetrader
-
Joined. -
Yep is done! Go ahead
-
The project structure changed a bit, but I tested it and it should work.
Did you do a new git clone from scratch?
Also, for your latest commits you need to checkout to exchain_apis_round2
And put the db inside src -
And I kept the old branch: ja/exchain_apis_old. But don’t do more commits on it, is only for reference
And xcpdev-genesis still has all the work as you left it, so you can also use it as a reference. But this one will be reverted to an old commit soon -
Keep the one you have, but try a new one from scratch. Will be much easier than trying to update the old project
-
J Loone Brickens 🧱 (@wasthatawolf) on XA brief history of Counterparty events starting Nov 2023... (🧵) - After the release of v9.61, J-Dog handed over lead maintainer duties to three devs... me, @shannonNullCode, and @jp_janssen. We accepted this role so J-Dog could offload the weight of this responsibility.
-
you could zero price data for now if wanting to use freewallet desktop with alternate api host?
-
After the separation of repos, yes. But that does not guarantee I will personally host it if is too inneficient
-
I would host the good DB player version 😆
Which can be totally based on the FULL replacement (but inefficient) version. I’ll do my adjustments on top of whatever you build -
Is not a bad idea to be the open source 100% replacement of the xchain api
-
Yes but it will take time to build all the queries exactly the same as exchain, also maybe for the 100% replacement API in the long term maybe is cool doing it in rust as is proposing and building here by @Jpcryptos was testing and retrieving the headers data of 50k blocks was done in 0.7 s
-
And is structured to be freewallet-specific compatible. Every path that starts with /api/ to be freewallet compatible. The rest (that don’t start with /api/) are the ones used by xcp.dev
-
I don’t think it would take THAT long… we slowed down mainly after realizing how damaging the queries were
But the code can have them. And then we can identify the worse heavy ones and be disabled with a config -
Well that's true
-
-
is it pushed ser? just pulled
-
cool ser going to check it
-
wow that was fast
-
good news here after the rollback now im in consensus back with xchain
-
messages hash still not matching but the other 2 are matching
-
what do u need to be documented? the wole process?
-
yes... lol
-
but at least ledger and txlist are synced
-
from my pc lol now he is happy at the end temperatures down of 72ºC
-
Aww 😭 lol is ok I guess I’m not an “ influencer “ anyway…
-
I beg to differ .. you are great influence
-
what Juan is not aware yet is that he is gonna be mentioned a time... or two... from now on -
A couple of new follows already 😆
-
That can happen with a reorg, just find where they diverge
-
Yeah I agree but that will explain the divergence
-
Devon added the undo table for reorgs a few years back and it actually works really well, ignoring the message hash issue lol
-
Basically allows a much simpler unwinding of one block automatically if a reorg is detected
-
Or however many blocks it takes although I don’t think we’ve had a multi block reorg in a long time
-
Have had multiple one block reorgs since ordinals started to become popular
-
It may have been, Devon was pretty thorough
-
As long as reorg triggers it, it’s something you want to happen immediately, want to get off the orphan block asap
-
It’s a feature of SQLite I believe
-
Would need to investigate more but it is something that’s been running for probly better part of 7 years and works well to keep nodes from crashing
-
But I agree should have a better way to indicate a reorg happened than a message since any nodes after wouldn’t have that message creating the hash issue
-
Reorg
-
Required manual restart
-
Sure, maybe not the ideal solution but it has a history of working well, certainly not opposed to something else
- 16 January 2024 (318 messages)
-
-
huge ser, works pretty fast, very interesting
-
retrieve first 1M issuances in 3.5 seconds wow 168 MB
-
yeah
-
is impressively
-
I have had on ymy list to dive in XCP and BTC dev more for a bit and this is the year that I'm starting. If I wanted to get started what is the best resource to work to get a node up and running and are there any other places that could help me get up to speed to start doing code wwalkthrus etc. I know this might not be the correct place. I was going to look to run a local node simular to how I'm running my ORD node. -
Some may not know me, but I'm an old C# dev and have working with MS stack (C#, SQL Server) for a long time but that is not particulay helpful.
-
ya I know lots of changes but would love to be reviewing the code so that at somepoint I can add value.
-
Not exactly protocol dev but important for preserving the "art layer" on top of Counterparty, and for building explorers:
Torrent with Counterparty images from xchain, imgur, easyasset etc.
https://jpjanssen.com/counterparty-image-archives/ -
That depends on how much token the dispensers holds and how much token it dispenses and how much token the tx with higest fee bought .. if some token left the second tx gets paid out too - but if not then thats a rugspeners from second tx point of view
-
Yes but worse. Rugspenser scripts use RBF to frontrun.
-
no, the past has already happened, unwinding blocks doesn’t break any sort of blockchain ethos
-
It “worked” when the community was small and you could request a refund from the seller (and usually get it). As the community has grown, we’ve seen more and more malicious actors exploiting this. -
its a tradeoff
-
it opened up a lot of liquidity too, millions of dollars have passed through dispensers that otherwise wouldnt have
-
It’s definitely the primary method of trade for counterparty
-
PSBTs wont work unless we can bind assets to utxos
-
thats why theres a list of “trusted” dispensers
-
and artists use it as a way to sell their tokens
-
so not really a risk in that regard
-
but we all recognize its a bastardized btcpay lol
-
yea for sure, but psbts also have their own drawbacks, nothing is perfect
-
if you want to “remove” a psbt sell offer you have to spend the utxo
-
its not a showstopper, just important to identify and be aware of so risk can be mitigated
-
and i think binding assets to utxos actually enables more interesting things such as “moving” assets off of counterparty entirely
-
it creates a sort of two way peg system
-
once your asset enters the utxo you’ve sort of locked in the block height and counterparty version until you return it back to the platform
-
in that way users can avoid fork drama, future updates they may not agree with, etc
-
this was the impetus for my proposal to integrate ordinal theory into counterparty
-
Ordinal Envelopes
An ordinal envelope is a mechanism that allows Counterparty assets to be moved into and out of an individual satoshi via its Ordinal number. From a technical perspective, this implementation is fairly straightforward. The challenge is convincing the Counterparty community that the rewards of integrating ord outweigh the potential risk to long term stability of the platform. I’m writing this post to eventually publish as a CIP so will keep the same format for portability… Abstract Ordinal nu...
-
ordinal theory actually fits very well in between counterparty and bitcoin
-
not inscriptions and all the logic around those
-
but simple sat identification
-
ordinals basically “solved” colored coins
-
by pre-coloring every sat
-
so if you follow the fairly simple sat id method, you create an overlay with which you can do fun things
-
as far as breaking fungibility, all it really does is expose the fact that bitcoin isnt really completely fungible in the first place
-
it doesnt really make it worse IMO
-
yea for sure, just a weak argument
-
and its still the maximalist argument against ordinals
-
the really interesting thing with ordinals is people then using ord to create new metaprotocols like brc-20 etc
-
basically people rediscovering the mastercoin/counterparty model 9 years later lol
-
yeah but VCs are just reacting right now
-
so someone spins up some random indexer and they go “shut up and take my money!”
-
hahaha i think thats his neutral state
-
we can certainly add more features/functionality without it, but what it does bring is interoperability
-
the lowest hanging fruit in bitcoin right now is creating bridges between indexers
-
sir, counterparty is a smart contract
-
ok
-
yeah its crazy how people hand over control of their wallets with a single signature
-
and thats totally normal
-
the marketplace experience with psbts is far superior, just needs to have better mechanisms for “delisting”
-
I've wondered for awhile, maybe this is a dumb question -
Is there a reason counterparty transactions don't support RBF?
-
Each archive is a zip file. I notarized these with Counterparty broadcasts.
The problem is the token-image relationship. In most cases there is nothing onchain. Only xchain, or at best imgur or easyasset links, both without hash.
In case xchain, imgur or easyassets shuts down, future block explorers can use these archives as image sources (ideally with explainer). -
Counterparty supports RBF. I use it all the time. I create cntrprty opreturn and send from Electrum.
-
Oh great
-
I see
-
so its just the freewallet implementation not utilizing it
-
up to the wallet in terms of how they are handling it
-
thanks
-
Correct
-
The dispenser is like the vending machine from the early days. Difference being the dispenser is on the protocol level.
For the seller it means no need to run a vending machine script 24/7 and only 1 tx to make N sales.
For the buyer I don't see much benefit. Why so popular? I guess a combo of risk willingness and ignorance. It's not like we've been good at communicating the risk.
The dispenser is no better than sending btc to a stranger and trusting they will send you the goods in return. -
the buyer benefits by only needing a single tx
-
and not waiting for an order match to confirm first
-
Compared to the DEX, yes.
This was vs vending machine. -
the order is filled automatically, theres no waiting for someone to send
-
No you don’t that was his analogy
-
you can get front-run by the seller, basically at no cost
-
Kinda, the front running buyer can be the seller.
-
There used to be a risk the person closes the dispenser on you, although that’s been mitigated with 5 block delay close
-
You have to trust the Seller. But everything IS automated.
Proble are:
1) The Seller can be at the same time the frontrun buyer with other wallet.
The most commun scam IS this one.
2) They can also close the dispenser before the buying TX goes throught. -
The risk right now is just anyone front running you
-
Obviously if it’s the seller it’s cheaper since they receive the funds
-
3) A real buyer empty the dispenser before you... But you can see unconfirmed TX on Xchain.
-
But anyone can front run
-
Since there’s no order match
-
(Bastardized btcpay)
-
No they are great for artists
-
Not everyone has that ability / skill set for one
-
For the seller they don’t need to trust anyone
-
Both the buyer and seller are typically ignorant of the trust assumptions, so it ends up working... most of the time.
-
For the buyer if dispenser owner is known it’s not really a risk either
-
And the biggest difference is no one needs to run an additional piece of software that requires uptime, maintenance, etc
-
I’ve seen a lot of artists use dispensers as their primary sales channel
-
Worth noting it would also be just as easy for them to create a btcpay Tx
-
So if we can get a better ux for btcpay I think many people would use it
-
That’s actually what rarepepewallet was before it was rarepepewallet, it was btcpaymarket
-
My attempt to make btcpay easier
-
BTCpay requires the Bitcoin to be received within 10 blocks. These days with the mempool the way it is, its not unreasonable for even a high fee to not confirm within 10 blocks.
-
20 blocks I think
-
But yea btcpay still has its own risks in a high fee environment
-
This could be done in the front with a single click isnt It?
-
To “cancel” all 3 solutions require a txn, so this is in no way unique to PSBT so I wouldn’t really consider this a UX issue for PSBT.
-
I mean it is, but no worse than the current solutions
-
To "cancel" you can buy yourself out of your own dispenser or create a close dispenser tx - both have same end result - dispenser is closed but one means moving btc to dispenser address whereas the other does not
Counterparty was recently updated to allow closing of dispensers from opening address - previously you could only close from the address dispenser was on so a self buyout could be done with a single tx -
previously one would have to send btc to dispenser address (less than the trigger amount) to then make the cancel tx
-
But my question is that even do there needs to be a cancel in two steps. There could be a button that says "cancel listings" that realizes one if the two options B0B said to cancel It on the back.
-
Sure on back end anything can be made to happen but at protocol level is what is discussed here
-
wallets can have all sorted of features - once you got private key you can sign txs to do things and not show each tx to user - just one big cancel button is enough to cancel all open dispensers but that may be half a dozen txs
-
wallets can also be built without private keys and as watch only - then cancelling 6 dispensers would be a faff
-
This IS then a great solution IMO, I dont see any drawbacks then.
-
what if you put a asset in a utxo then use that utxo without counterparty? is asset then stuck forever in a utxo that no longer exists?
-
or will it be un escrowed? back to origin address?
-
yeah needs to be considered as some user will have that accident i bet
-
or it will be used as a type of burn
-
So would have to be from same address only else how do you know its real.
-
not if user traps a asset its not
-
protocol has to be able to recognise the redeem
-
yeah .. if that is what is is done. I just pointing out putting a token in a utxo does not guarantee that utxo will interact with that token it (the utxo) may be used elsewhere
-
users will find a way to do what was not intended
-
The advantage with using sat id from ordinal theory is that utxo tracking is already solved
-
ppl use electrum to consolidate counterparty address utxos all the time
-
it does not understand counterparty and not every wallet will nor should
-
You have to use a separate derivation path for utxo based assets
-
and i can derivate anything from a seed if i want
-
You can’t have them all under one address it would be a ux nightmare
-
but its tied to a utxo not a address
-
it needs a lot of thought
-
Yes but that utxo is tied to an address
-
yeah and you cant stop people using them in other wallets is all i am pointing out
-
Any update to counterparty that involves binding assets to utxos or sat ids needs to come with a sort of best practices guide
-
As a wallet developer I would simply use a slightly different derivation path for anything utxo or sat based
-
for sure - and as many fail safe mechanisims as can be reasonably provided
-
This way segregating them from the counterparty address
-
yeah i think that needs making very clear
-
100%
-
I like the sat id method for a lot of reasons, one being you can send to sats you don’t control
-
i expect ords have been lost due to lack of user knowledge - i know people have used p2sh-segwit to buy from dispenser and its a pain in the butt but you can get it back using op return tools from JPJA
-
you hear dotn use a 3address - which is poor advise as p2sh 3 addresses are fine
-
so are the segwit type if you know how to drive them
-
can taproot do a op return? i expect it can yet users are adivsed to not use for dispenses
-
Counterparty doesn’t recognize taproot addresses
-
understood re taproot but the 3address thing my point stands - they work fine we just lack wallet and or api support and user education on the various 3address types
-
TheStampWallet.com has implemented 3address support.
-
p2sh multisig and wrapped segwit ?
-
Hmm… don’t know it well enough to say.
-
i expect just the latter
-
counterparty cant know if its p2sh or p2sh-wrapped segwit from just the address it would need to see redeemScript
-
Both ordinals infrastructre and or counterparty infra needs a tx to move a asset ... so if counterparty allows ord infra transfers it will need tracking by cp incase a counterparty infra method is used later
-
Practically, it can only be implemented by selecting a subset of transactions.
Tracking every single sat of every transaction is a many terabytes (or even more) I heard Casey mention once. And it would be resource intensive. And each day becoming harder as the sat ranges break up and get mixed… -
I would let ord be ord, and cntrprty is separate. Maybe utxo can make sense for special stuff though…
-
Yeah is the abstraction they use. An optimization instead of literally tracking every single sat atomically
-
Thoughts on atomic swaps?
https://github.com/CounterpartyXCP/cips/discussions/100Atomic Swaps: Advancing Decentralized Asset Exchange and Trust Minimization · CounterpartyXCP/Forum · Discussion #100Introduction: Atomic swaps enable direct peer-to-peer asset exchange between Bitcoin and Counterparty assets without the need for intermediaries or trusted third parties. They utilize Hash Time Loc...
-
i ran satindex for a while it is certainly not terrabytes
-
but it is a lot of overhead, like 200gb-ish
-
it is fast tho, i had a simple python script that used ord to ID the sat in op_return for the transfer back to counterparty
-
the issue i ran into at the time was ord db getting corrupted on reorg
-
you could front run it yoursef
-
and you could do it with different utxos
-
thats the crux of it, since the counterparty balance is abstracted to an address layer you dont get the benefit of double spend protection
-
p2sh only needs 1 tx to move asset to get colab custody according to L1
-
Well but this is only tracking the sats for ‘ord’ enveloped taproot transactions, right? Is a very small subset of every single sat of every transaction…
-
send asset to a 2of3
-
1 tx
-
now 2 of 3 needed to move it again
-
lol indeed
-
You could be all the sigs in a multisig if you wanted - 1 tx to upgrade from a 1/1 to a 2/3
-
you get the added security of a 2/3 with just a single tx from a single sig. You need to know your op_returns to spend it. You may not know all the counterparties in the multisig either
-
I was thinking of a brokered multisig application where buyer and seller may not k ow each other
-
they may know each others pubkeys only
-
they don't even need go know what each other is paying or selling price is but will find out when it's setteled
-
yeah each party knows at least one other but not all parties
-
no mostly just the code to implement it
-
I drew some flowcharts on a whiteboard to help me not forget stuff
-
figured i would build and then anyone can see the code as its mostly clientside js .. could hide tx creation behind a python tho
-
Who is a frontend dev here?? Would like to know your thoughts: https://github.com/CNTRPRTY/xcpdev-ssr/issues/1Web server stack · Issue #1 · CNTRPRTY/xcpdev-ssr
This is the place to discuss the alternatives to implement the server (side) rendered version of xcpdev. The main requirement is having FULL control of the server. This IS the software being build,...
-
I was trying to help people not get scammed by using a multisig
-
What ur looking for ‘universal’ or ‘isomorphic’ SSR apps - you could go the angular route for this but most will be familiar with react methods - this next.js I have no personal experience with but have looked into and should, so long as you have a node js server it will be able to do the SSR for content if used right, if you aren’t keen on that what people used to do in place. I’m sure there are other methods for react SSR too but I think nextJS is currently most popular for this
-
of course its not perfect - broker reputation is part of it as it is in broker interest to not scam
-
What would be cool on the sever side is perhaps a socket.io push stream of counterparty messages - could enable some for tenders to do some cool stuffs
-
zmq?
-
nope, it will give you sat tracking for any output
-
Err maybe - like pushing event objects to subscriber groups on the FE client
-
because the method for returning to counterparty is burning that single sat in an op_return output then the range is a single sat
-
It’s very cheap as it’s one message stream and can serve a lot of listeners for little overheads
-
you did this - its on chain right?
-
yes, i did it as performance art lol
-
i’ll find the tx
-
i have seen the api command to burn btc in op_return
-
i spent a stamp for the same reason
-
J Loone Brickens 🧱 (@wasthatawolf) on X
Yo dawg, I heard you like teleburns. You can now teleburn your ordinals via Counterparty asset issuance.
-
so 1 ord sat can become 100000000 ordteleburn counterparty 'sats'
-
yep
-
This is how works in ordinals bc you are transferring SATs but here you could add an end block in the op return teorically where the offer ends right?
-
nice - so ords can be fractionalised like the naka was but without using eth
-
I guess you can destroy a cp asset into a ord ?
-
Would you recommend adding angular to the list of alternatives to consider??
-
little bit of dust change with a burn address and you got a cp asset to and ord and then back again to fractionalised ord on cp
-
React kinda won market share in that battle, but if you like to run a tight ship angular with TS is for sure an option I would worry that maybe it’s overcomplicated at times, react a bit more suited to letting people hit the ground running when entering a project
-
Maybe for a next phase, not doing real-time mempool just to keep the core simple. But maybe something to consider for memepool.wtf ??
-
I was running angular front end with a nestJS server which was kinda cool as nestJS has a lot of angularesqueness to it
-
Oh in your wallet then? I remember I checked very early on so maybe is something they were able to optimize…?
-
Yeh would be a ‘nice to have’ that allows for experimental fun, but also can assist with things like real-time updates on the front end - you are getting to offset polling functions for an event listener which is pretty dope
-
Yeah I’m in the react camp, sorry for angular then lol
-
Oh wow. This is an additional modification to the trx after you create the cp trx from the API I suspect. Will be curious to do on bitcoin core for sure
-
Ehehehe
-
Yep right in ord using the —satindex flag
-
Oh I realize we are just talking about the sat ranges. Yeah that is not too bad… for now lol
-
And you could maybe still using account base for reception so you bind to the utxo in the list/send and unbind when you receive it automatically
-
Electrum-Counterparty/decode_tx.html at master · Jpja/Electrum-Counterparty
Generate OP_RETURN for sending Counterparty tokens from Electrum - Jpja/Electrum-Counterparty
-
that's the best tool to help .. the txid is used to decode the countrrparty message inside the tx line 141
XCP Dev Chat
Public archive of Telegram messages.
- 05 Jan 2024 (37)
- 07 Jan 2024 (187)
- 08 Jan 2024 (332)
- 09 Jan 2024 (865)
- 10 Jan 2024 (479)
- 11 Jan 2024 (508)
- 12 Jan 2024 (685)
- 13 Jan 2024 (674)
- 14 Jan 2024 (319)
- 15 Jan 2024 (104)
- 16 Jan 2024 (318)
- 17 Jan 2024 (24)
- 18 Jan 2024 (10)
- 19 Jan 2024 (3)
- 20 Jan 2024 (22)
- 21 Jan 2024 (1)
- 22 Jan 2024 (33)
- 23 Jan 2024 (11)
- 24 Jan 2024 (19)
- 25 Jan 2024 (294)
- 26 Jan 2024 (189)
- 27 Jan 2024 (65)
- 28 Jan 2024 (7)
- 29 Jan 2024 (8)
- 30 Jan 2024 (62)
- 31 Jan 2024 (110)