- 13 January 2024 (674 messages)
-
idk, im not seeing hashes in my node be the same like xchain or xcpdev -
so im wondering if triggering a reparse could fix it
-
ledger hashes, txhashes and messages hashes mismatching between my node and xchain and xcpdev
-
so reparse could be the solution? is what i was wondering to know bc certainly i dont know, okey i will try it
-
no bootstrap right
-
xchain uses it
-
xcp dev dont use it but didnt do a full parse with the new version update i think
-
yes
-
i did a full parse without bootstrap in 9.61
-
i am not sure
-
no ser
-
they dont match neither
-
3 different set of hashes between me xchain and xcpdev
-
memepool.wtf matches with xchain but i assume is because they are using the bootstrap?
-
re org can effect ledger hashes if seen by 1 node but not another -
anyway, when i connected the stamps indexer to my node and a new block is mined i have this error sometimes, maybe is related :
[2024-01-13 16:34:52][ERROR] API Exception: {'type': 'BusyError', 'args': ('BusyError: database is locked',), 'message': 'BusyError: database is locked'}
federatednode-counterparty-1 | Traceback (most recent call last):
federatednode-counterparty-1 | File "/usr/local/lib/python3.6/dist-packages/jsonrpc/manager.py", line 108, in _get_responses
federatednode-counterparty-1 | result = method(*request.args, **request.kwargs)
federatednode-counterparty-1 | File "/counterparty-lib/counterpartylib/lib/api.py", line 687, in get_method
federatednode-counterparty-1 | return get_rows(self.db, table=table, **kwargs)
federatednode-counterparty-1 | File "/counterparty-lib/counterpartylib/lib/api.py", line 287, in get_rows
federatednode-counterparty-1 | query_result = db_query(db, statement, tuple(bindings))
federatednode-counterparty-1 | File "/counterparty-lib/counterpartylib/lib/api.py", line 144, in db_query
federatednode-counterparty-1 | results = list(cursor.execute(statement, bindings))
federatednode-counterparty-1 | File "src/cursor.c", line 236, in resetcursor
federatednode-counterparty-1 | apsw.BusyError: BusyError: database is locked -
is what i thought but... is the only strange thing/problem i had during parsing so wanted to mention it
-
im 1000% with your vision ser
-
Only message hashes -
Ledger hashes should be the same
-
this is what is needed i strongly believe that tests was passing when updates happened
-
It’s not hard to dig back and find where they diverge
-
if you show me the road i can try to dig in it, but is my first experience with a cp node
-
Am I wrong to be concerned with just disclosed information in the other counterparty chat? -
Domains don’t define counterparty as we’ve seen
-
Neither do repos for that matter
-
my bad i was on mobile device and typing rarepepe mike was too much
-
hash miss matches are why bootstrap got made ..@uanbtc
-
hmm can't link him
-
@uanbtc
-
this is just another patch... doesnt solves the underlaying issue
-
my bad
is why nobootstrap got made -
opps that was a silly mistake apologies
-
it was matching until yesterday yes
-
nobs mode .. speaks for itself
-
i dont know which one is the discordant
-
if someone can help me to dig on it i can check it
-
or i can send you the counterparty.db if is easier to check in your side as i never did this before but i prefere the learning path
-
no i said i was matching with xcp dev
-
i have been sending periodically blocks that matches to @uanbtc so i can see the last one i was matching with him
-
now i am not matching
-
i will check
-
i think the best way is through the api right?
-
i will try to create a basic script for this
-
interacting with cp api and checking hashes
-
yes ser i can do it through the db but as i dont have xchain db i cannot check against so do it through the api is the way that this script would be reusable for others to check it
-
preferred language?
-
python or ts?
-
okey
-
there is some code on git about this I believe .. to do with recent changes
-
--no-bootstrap installation option by pataegrillo · Pull Request #342 · CounterpartyXCP/federatednode
Federated Node Build System. Contribute to CounterpartyXCP/federatednode development by creating an account on GitHub.
-
- NO_BOOTSTRAP option and selective bootstrap downloading by pataegrillo · Pull Request #1218 · CounterpartyXCP/counterparty-lib
Passing a new parameter NO_BOOTSTRAP to disable bootstrap downloading and start parsing from scratch Passing a new parameter BTC_NETWORK to make mainnet container only download the mainnet bootst...
-
Bootstrap database has incorrect "ledger_hash" and "txlist_hash" ..? · Issue #1031 · CounterpartyXCP/counterparty-lib
Hi, I found that my own counterparty testnet node has different ledger_hash and txlist_hash compared to testnet.xchain.io. As far as I found out that the bootstrap database has different ledger_has...
-
stop forcing database integrity check on startup · Issue #1192 · CounterpartyXCP/counterparty-lib
Currently we do a database integrity check when counterparty starts up, and at times this integrity check can take a very long time to complete if it has been a while since CP has restarted. The en...
-
nah we ain't got time for that 🤣
-
Deferred. -
You’re so there.
-
Been saying that all along.
-
i have runing the script to check where the hashes diverge
-
it could take long i think
-
yes lol jajaja
-
Juan must have useful info here
-
dont deserve, when i am sure that is working the script i will push to CNTRPRTY repo
-
Competitor based off of repo location alone. It’s a window into the bigger picture that I have been saying for a week.
-
GitHub - jdogresorg/Broadcast-Token-Naming-System: Broadcast Token Naming System (BTNS) specs, docs, and tools
Broadcast Token Naming System (BTNS) specs, docs, and tools - jdogresorg/Broadcast-Token-Naming-System
-
Similar to ‘Stamps and company’ (numbered only)
-
Not really. Stamps use dispensers and other native CP features and do require xcp for things like sweep. BTNS is entirely dislocated from xcp and counterparty features. The same criticism against src20 (which was migrated off of counterparty early on) -
I would like this to be part of the lib api -
that was a python script running on flask server
-
Yes!!
-
I don’t think they are. The protocol is the hashes. The lib is an utility to the protocol
-
Bookmark for later. I have a real life.
-
I expect a good dev could do something .. I could share my python to help
-
1 get all txid ever made by address
2 check every utxo of every tx for unspent spendable dust
simples -
to exclude stamps will need to decode counterparty data and look for stamp: or something 🤔
-
could get list of stamps to exclude from api first perhaps
-
It is build to include the genesis divisibility, taken from the issuance table, based on the genesis block from the asset table
Is the most efficient single query that contains the divisible property that I have come up with. Open to optimizations
This divisibility, and the ux expectancy of always showing the latest description, are big bottlenecks in the current DB schema
The description is solvable by simply doing different UX. The other, divisibility, is more deep -
looks like the btns example in cip long enough to make multisig 'dust' n 'abuse' utxo if not swept
https://github.com/CounterpartyXCP/cips/blob/master/cip-0028.mdcips/cip-0028.md at master · CounterpartyXCP/cipsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Example 4: bt:DEPLOY|TEST|100|1|0||1|1JDogZS6tQcSxwfxhv6XKKjcyicYA4Feev|1JDogZS6tQcSxwfxhv6XKKjcyicYA4Feev
that's not fitting in a op return -
Thissssss
-
Full parse as default is how I would do the consensus protocol app. Is so backwards that the bootstrap is the default
-
@uanbtc I made a bad typo
-
Cool. The bootstrap is also a reason block parsing optimizations have been neglected
-
this is the last block i am in consensus with xcpdev:
{
"ledger_hash": true,
"txlist_hash": true,
"messages_hash": true,
"block_index_ledger_match": 819576,
"block_index_tx_match": 819576,
"block_index_msg_match": 819576,
"block_index": 0,
"last_block": 819576
} -
825670-819576 = 6094
-
6 weeks
-
will check now me against api.counterparty.io
-
this is me against api.counterparty.io matching txlist and ledger hashes:
{
"ledger_hash": true,
"txlist_hash": true,
"messages_hash": false,
"block_index_ledger_match": 825095,
"block_index_tx_match": 825114,
"block_index_msg_match": 0,
"block_index": 0,
"last_block": 825089
} -
will do it now with coindaddy, this is the one that uses xchain right?
-
When your checks are done ... last comment on this thread may help ?
https://github.com/CounterpartyXCP/counterparty-lib/issues/1240#issuecomment-1745777884Tx included in v9.60.1 but not in v9.60.2 · Issue #1240 · CounterpartyXCP/counterparty-libThis dispense is shown on xcp.dev - https://www.xcp.dev/tx/16bd438b1dee6b1f750758eeabef7a876c204082a088c48ca51c416d6651d5db It is not a Counterparty tx according to xchain - https://xchain.io/tx/16...
-
if it happened before eh
-
@teysol
-
dont seems to have happened before is between 825100 and 825200
-
doing binnary search using the script
-
I mean it's a documented event in the past it could happen again
-
ah okey yes for sure...
-
okey this is me against public.coindaddy.io
{
"ledger_hash": true,
"txlist_hash": true,
"messages_hash": false,
"block_index_ledger_match": 825095,
"block_index_tx_match": 825114,
"block_index_msg_match": 0,
"block_index": 0,
"last_block": 825094
} -
not same block but very close
-
yes both api.counterparty and public.coindaddy diverge from mine in same block (please just check the ones ending with match)
-
I don't have a node running at the moment
-
ah yes I see ty
-
So if its 'failed rollbacks' and the issues can be tidied up its not so bad .. but it needs to clean itself as it goes .. if hashes are found to mismatch with multiple unconnected peers then I need take a look at myself
-
If is a thing of a rollback if I run a reparse should it be fixed?
-
I don't know how to do this using fednode so if someone can say me I can do it no problem
-
This
-
Thanks for your help
-
from the docs. have no idea if they're out of date
-
Thanks ser
-
We need to invest some time in docs when we fix all this issues
-
we should get robbyrbd here
-
@uanbtc how much Counterblock do you know ?
-
I know the main get status api changes with additional infos when's it up but that's about it ... finding the html/js to play with took a while but I did n it seems to be copied at run time and you have to stop restart to try n get it to load changes ... painfull n think that's why I gave up
but if it could give json info to power wallet be nice -
0. Haven’t used it because is not core to the protocol
-
Only my first time learning
-
json data like xchain is needed don't care where it comes from in Counter party block whatever
-
can it be made REST GET not POST ?
-
http post is doable in browser now a day but feel a lot more effort .. is post it slower? I wonder too
-
fednode rollback 724000 counterparty
-
v9.59,6 release notes
Fixes issue with dispensers not working with addresses that start with 3 (p2sh addresses)
Upgrade Procedure
For those running a federated node you should run the following commands:
cd federatednode/ fednode update counterparty counterparty-testnet fednode rebuild counterparty counterparty-testnet fednode rollback 724000 counterparty fednode start counterparty -
there's the rollback command
-
the docs linked from repo fail
https://counterparty.io/docs/federated_node/Running a Node | CounterpartyInstallation/federated_node.md
-
what's the docs site anyone ?
-
-
yeah was just a example for @XJA77
-
Nice to have you here @robbyrbd
-
docs are soo dated too
https://docs.counterparty.io/docs/advanced/advanced-usage/multisig/
p2sh support been partially added
we can use p2sh just don't have counterparty api supportUsing multisig with counterparty-server | Counterparty"Bare Multisig" (i.e. not P2SH) is supported with Counterparty. This document shows you how to use it with counterparty-server on testnet.
-
we can send n receive from p2sh even dispense from 👍
-
I expect dex works too for p2sh not tried it tho
-
yeah but it's not clear to users multisig is fine I don't see p2sh support infact it says opposite
https://github.com/CounterpartyXCP/Documentation/blob/master/Developers/Notes_and_Tutorials/multisig_counterparty-server.mdDocumentation/Developers/Notes_and_Tutorials/multisig_counterparty-server.md at master · CounterpartyXCP/DocumentationOfficial Documentation of the Counterparty Project - CounterpartyXCP/Documentation
-
so docs are outdated
-
no users use bare multisg and not many use p2sh .. I am sure if you trawl the git issues you will find stuff but not great
-
yeah I have used it
-
works well 👍
-
but you got to make custom op returns at this time ..is issue on git about it and Adam has commented
-
but docs needs to be current please
-
I not talking data encoding I talking 3 type addresses for every day use
-
Stamps is built on this, yes
-
we use opreturn to send asset from p2sh manually
-
multisig data encoding is one thing
p2sh colab custody another -
I don't find I can sorry
-
ahh OK I will try to look at that I didn't know
-
wil be nice to update the doc ty
-
and if we get p2sh api stuff will be magic
-
ahh OK yeah makes sense .. I need to get me a git gui n get busy .. will update docs n push my p2sh address builder tool
-
ty
-
Cool I will try reparse first and if not i can do a rollback
-
As there are differents blocks where lost consensus I think I will go with the lower one and see, hopefully reparse solves something, if not rollback
-
sounds like I could do that if I tried ...I never really done much git
-
yes and you can force baremultisig to encode data even if op return is a viability if you want that utxoset residence
-
Also stamps goes directly to multisig in issuances
-
yes you force it on the api
-
no way that's funny
-
what's your opinion of burn keys ? do you know of it ?
-
forced dust return pubkey
https://github.com/mikeinspace/stamps/blob/main/Key-Burn.mdstamps/Key-Burn.md at main · mikeinspace/stampsContribute to mikeinspace/stamps development by creating an account on GitHub.
-
so makes it unspendable utxoset permenance
-
artists can't rug a counterparty token buyer if its unspendable and remove artwork from utxoset
-
another issue to consider, for me hs not many sense that counterparty service brokes if there is a database lock IMO
federatednode-counterparty-1 | [2024-01-13 21:49:52][ERROR] Unhandled Exception
federatednode-counterparty-1 | Traceback (most recent call last):
federatednode-counterparty-1 | File "/usr/local/bin/counterparty-server", line 11, in <module>
federatednode-counterparty-1 | load_entry_point('counterparty-cli', 'console_scripts', 'counterparty-server')()
federatednode-counterparty-1 | File "/counterparty-cli/counterpartycli/__init__.py", line 16, in server_main
federatednode-counterparty-1 | server.main()
federatednode-counterparty-1 | File "/counterparty-cli/counterpartycli/server.py", line 174, in main
federatednode-counterparty-1 | server.start_all(db)
federatednode-counterparty-1 | File "/counterparty-lib/counterpartylib/server.py", line 499, in start_all
federatednode-counterparty-1 | blocks.follow(db)
federatednode-counterparty-1 | File "/counterparty-lib/counterpartylib/lib/blocks.py", line 1483, in follow
federatednode-counterparty-1 | new_ledger_hash, new_txlist_hash, new_messages_hash, found_messages_hash = parse_block(db, block_index, block_time)
federatednode-counterparty-1 | apsw.BusyError: BusyError: database is locked
federatednode-counterparty-1 exited with code 0 -
making it unspendable at same time
-
it makes no spending key
-
and did it clean up dust ? no I don't think it did
-
I found 10btc in counterparty unspent multisig encoded dust . you may have a few million sats / $ you can reclaim
-
@uanbtc seems it here maybe ? dust
-
indeed is interesting stuff ty
-
GN
-
Update on xvp.dev
I have the homepage, blocks, tx and address pages done so far.
I'm currently working on the wallet page.
After that I think there is just one more to go (asset) and we can push to prod (xcp.dev).
@uanbtc can you confirm that is the final page?
So far they look like this (see the left side) -
-
-
wizard
-
there is a tx page too @uanbtc
https://www.xcp.dev/tx/b461cd41e5616ac8ef58cda765c358b9d76d4189d108402c0e686f6eea9cf7b8 -
looks very nice 👌
-
Wait I forgot about that, I did that also 🤣
-
That's awesome ser
-
Change the xcp.dev address
-
That is wrong with a typo
-
Bookmark 2. Catching up. Be back later.
-
Three and done for now
-
Tennessee 2024 is going to be great.
-
wen dark mode -
- 14 January 2024 (319 messages)
-
Plz my optimistrist said so
-
Pinned for notice. Clarifying etiquette should not have to be part of the room description.
Those who only contribute extraneous dialog will be silenced if they continue after two warnings, each by a separate dev, admin or mod
Those who are overtly disruptive will removed.
No drama. No politics
Thanks for understanding -
None
-
I want to bump this instead of link it again. from earlier this year. came up in conversation, twice so far. so it is on anyone else's radar if helpful.
re: using Counterparty with Electrum -
one of the ways users have funded open development is by using auctions. The community comes together to donate cryptoart to one wallet for this cause. Everything in the wallet is the lot. if the auction house sent the winning bid, minus fees to said worker, then that would be the most direct route to raise funds at this time, with no "official counterparty organization on paper with an accountant" needed afaik.
there are a few auction houses which would likely participate. maybe more than one would be willing. Something like this could take place, before or during improvements. But the biggest yields/result would be after the casual users can feel safe again.
also, instead of an auction house, everything could be vaulted on emblem and the whole lot auctioned on/with eth.
this is the kind of non-development objective I think that the @xcpfoundation participants should be able to handle. I know I'm willing to plan for something like this in that room as to stay on topic -
for several reasons.
I would advise the recipient to set up their own wallet, so they have the option to hold onto anything that interests them. Then they can send the cards they don't want to keep to the auction house for BTC/eth -
we will have another a month or two afterwards 🍀
until the goal is reached 🎉 -
🌡
-
There is a new one with hardware wallet support: https://rarepepewallet.wtf/Rare Pepe Wallet
Collect rare pepes and mint new pepes on Bitcoin.
-
pepe.wtf is very cool for that
-
Check out xcp.ninja
Has all the collections and you can paste your address to see what you hold -
That particular stamp uses the src721 spec created by @herpenstein it’s a method of using json to point at a number of pre-minted “traits” as 10K pfp collections tend to have a lot in common. So it removes all the redundancy across a collection.
-
how is the thing to run it?
-
i want to give it a test, im having issues with the api in cp-lserver
-
maybe this solves the issues and if i can use the same syntax can work for me, what is the name for the DB env var?
-
what is the name of the env var that i need to put in the .env? i dont see it in the README
-
will give it a try im tired of having to restart counterparty service all the time...
-
working on this so i can do the reparse aswell in cp
-
None
-
-
yes this is the block
-
there are more
-
but this is the one i did mention
-
but there are others blocjs
-
i like the idea of have an optional service for api that can be run separately of the core so can scale apart but im not very familiar with rust and i cannot have more hours in the day im working 16h/day full in counterparty and stamps
-
good part is i love my work :)
-
GitHub - JavierCervilla/COUNTERPARTY_UTILS: Aim of this repo is to be a recopilation of utils scripts and tools for Counterparty node operators and users. Feel free to fork and create PRs against it to improve it.
Aim of this repo is to be a recopilation of utils scripts and tools for Counterparty node operators and users. Feel free to fork and create PRs against it to improve it. - JavierCervilla/COUNTERPAR...
-
pushed here the consensus check script if is util for someone
-
@uanbtc could be cool adding it to your github repos if you want, feel free to fork it
-
@uanbtc has some CIPS around it
-
Some duplication is fine, is denormalized where it makes sense, the most common ways to query each table
Is things like descriptions that don’t need to be copied so much, I believe. Very problematic with sweeps -
But
We could just not copy the description. Is what I have been mentioning that the expected “last description” is the one from the last issuance row is again, problematic -
Address and txid yea maybe
-
broadcasts znd dex trades are not too much .. my wallet had them using cp api to generate the tx hex ... a beiadcast no different to z issuance really in client wallet it's just a type of counterparty message
wallet calls cp api gets returned txhex signs and sends ... what's needed tho to go with it is broadcast history dex trades etc
we have seen broadcasts used by devs to initiate actions in mint servers -
so user buys token.. does a destruction with memo.. causes app to do a function .. generative artwork made znd attached to token .. questfrens did this
-
please don't take broadcasts destructions dex trades and stuff out of wallet specs they nice .. appreciate tho they not as urgent as fixing protocol but from user wallet perspective they are what make counterparty fun
-
I was gonna get ppl to name their soldier (satoshi solider) using a broadcast
-
pinataxcp did stuff like this too .. servers detect onchain message from token holders
-
sure trading is fun but so much more is possible once have a wallet
-
here is my destroy tx (watch only mode wallet ) .. now also shows txhex as qr
-
we make stamps to destroy on purpose 👍
-
I like the verification against coinbn so cool
-
that was before freewalket decoded but I like to verify n encourage users to verify
-
maybe we need a tx decoder tool for all like coinb.in
-
Coinbn.in is not open right?
-
yeah it is
-
but doesnt understand cpunterparty
-
just sees op return not the decoded data
-
Jpja reverse engineer tools handy here
-
Mmmm should be easy add arc4 there? Or not
-
Yes this is very cool tool
-
yeah I think it will
-
to do a dex page for a asset you need order history .. open orders bid and ask and ability to place a order ..so many api calls pages get slow ..maybe counterblock is better to use ?
-
broadcast in watch only mode
-
-
will need to remove links to BTNS haha
-
Electrum-Counterparty/js/xcp at master · Jpja/Electrum-CounterpartyGenerate OP_RETURN for sending Counterparty tokens from Electrum - Jpja/Electrum-Counterparty
-
yeah I love it
-
reverse engineer stuuff takes time but so cool
-
Tnx, it's my pet project. Far from complete. Hope it can be useful for
-
other wallets too. Solution to blind signing
-
I use it to make op return hex and compare with cp api generated op return hex to know I got it right
-
yeah if we decode tx hex and op return and verify then is not blind sign
-
So... what is this?
-
Multiple attempts at a Overspent disprnsooooor? -
Which block is it?
-
im getting an error on reparse after one of this warning
-
Reparse from start
-
Strange
-
This one was stop matching at this exactly block
-
Will need to check against xcp dev later the script again
-
Okey with xchain is the same
-
-
Let me check
-
8 hours
-
Better lol with all the nodes using bootstrap less xcpdev there are not any good reference...
-
Oh yes true didn't think that
-
Yes 8 hours is good
-
I need to check better what is doing exactly in a reparse and what checks in it
-
Next step in my node would be a rollback from this block right?
-
Challenge accepted! Let’s go!!!
-
Team work makes the dream work
-
Sounds good. Thank you
-
Peter Todd python lib is fast bitcoind slooow
-
I was using Peter Todd's when scanning chain for unspent dust
-
this is seed signer hww integration too BTW.. it loves a qr code that lil device
-
I am finding g it hard to get testnet utxos from free apis and broadcast testnet tx .... if we get a bit more bitcoin in counterparty this dev pain point goes away
-
Why 753? It will take another week
-
-
-
-
I'm thinking on xcpdev and I think we have a really good opportunity to educate users from there, we can add tooltips that explain some things for example in the messages (in counterparty every action in handled as messages) topical question mark that when you hover in it open a dialog with the info
-
Okey better lol
-
So it's like 5 api calls for a asset market page
open dispensers
dispenser history
dex history
bids
asks
if you exclude dispensers ppl can 'lose money' as they maybe don't see recent sales and true market price -
a RAREPEPE was recently sold for 1,000,000 PEPECASH its suspect user didn't know what they had an under priced it massively. It was snapped up in a heartbeat
-
yeah I get a link
-
GitHub - petertodd/python-bitcoinlib: Python3 library providing an easy interface to the Bitcoin data structures and protocol.
Python3 library providing an easy interface to the Bitcoin data structures and protocol. - petertodd/python-bitcoinlib
-
I dunno I found it years ago and used it as it seems faster that bitcoin http rpc python stuffs
I heard miners use it so guessed was the fastest as to miners time is important -
I hope it help speed up stuffs 🤞
-
python 3 too so should mesh well with the work your doing
-
Yeah that is a counterparty-lib dependency but probly hasn’t been updated in a while
-
Sounds about right
-
btns is pure broadcast no cp assets, so more 'abusive' than stamps and can't use most cp features
-
assumevalid=0
-
it didn't even have a actual release bitd
-
im starting rollback from block 824000 12 days ago it will take some time for sure
-
strange i think undolog has 100 blocks as limit maybe?
-
i believe the undolog is for re-orgs so it would make sense to have a sensible limit on it
-
But I don't see the difference then between rollback and reparse
-
I thought rollback will delete all blocks after the one specified and start checking tx from there but it triggers a re-parse instead? Unless it trigger re-parse until the specified block and start parsing from it
-
Anyway let see what it does
-
can xcp.dev be easily updated to show an assets subassets ?
-
It shows them https://www.xcp.dev/asset/OTHERWORLD
-
🔥🔥🔥🔥🔥🔥🔥🔥🔥
-
I like this a lot!
Thinking the default xcp.dev becomes the community version with nice ui and more minor detailed features like this one.
But I kind of like the simplistic minimalistic “genesis” version of the website. And want to keep it alive in some capacity.
And thinking this can also become the “embedded” option, not competing with the style of the website is on. Like https://www.vivalavandal.biz/ did
Waiting for any feedback before moving ahead with this:
https://github.com/CNTRPRTY/xcpdev/issues/17Split repo · Issue #17 · CNTRPRTY/xcpdev@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...
-
is there a testnet xcp.dev?
-
No, only because of trying to minimize my costs. Should definitely be available eventually
-
totally get that ... what's the cost for a testnet instance to run for a year?
-
Is part of the same fednode. But having it off means I can have a smaller more economical server be more performant
-
Yes I’m open to this. But my initial focus was on providing the ease of onboarding for MORE nodes!
-
I would love to see a testnet instance n could sell a few cards to fund it
-
This is my point. I believe the best move is to allow the default xcp.dev to flourish with community contributions.
And I can just continue keeping the original xcpdev alive in some non-www subdomain for the people that like the minimalistic design. -
Will definitely have it in mind. And is just a natural, xcpdev is educational
-
Understood
If anyone else wants a testnet xcp.dev let's chat and we can setup a honeypot for it ... we can then pool some cards n take em to auction .. hopefully the community want to see one -
too late.. there is already one I believe .. its called the naka honeypot for $bag
-
@IndelibleTrade
-
do you know of the $bag?
-
Ehehe
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)