- 27 February 2024 (447 messages)
-
And thats fine -
Who cares
-
You care -
Nobody was willing to just say, we want to burn more xcp, to increase the price for owners
-
that's it
-
I just didn't see what the explanation was otherwise
-
That’s one reductionist dimension.
-
No one has to accept your frame
-
Of course not
-
You guys are free to do what you want
-
You need to make the success of Counterparty more tied to the success of XCP to get nice things or else the incentives are misaligned. And what you get are competing solutions to Counterparty instead of better Counterparty. And users, if that is your constituency of concern, however loosely or hand-wavy you define “user”, are left in a tragedy of the commons situation, like if their town stopped picking up trash or maintaining the sewers. No nodes, no wallets, no updates to code, no support for new address types, we’ve skated close to all of these things for years. JDog prevented the worst of those outcomes. But rearchitecting the incentives towards XCP creates a new opportunity, not a guarantee, for better services and tech for users because there is a carrot there for investor-developers. And users too can participate in the economic upside. Even if you don’t own XCP. For example, your existing project built without certain fees has a grandfathered advantage. It’s not useful to create thick boundaries of user vs dev or whatever other bucket. Most people play more than one role. And this is cryptocurrency, it’s not save the world altruism. We’re building public domain flywheels, usually the benefits of which are fully privatized. Counterparty has been spinning but its energy has not been properly focused.
-
Yeah, I got what you meant.
-
I was just frustrated I had to dig
-
So far, those incentives already exist for owners, as its already deflationary.
-
Hardly
-
So tweak the tokenomics to get the price higher, rewarding holders
-
Which I would assume the devs are holders
-
Is that what you are imagining?
-
Ok, so you are onboard with the idea generally.
-
I wanted some to just say it
-
that's all
-
It’s polite in crypto not to ask. Like it’s polite to not ask people if when they say “historic NFT” is it not just to make the number go up.
-
And I’m just speaking to my own experience, I don’t know anyone’s plans or thoughts. I know I’ve bought a bag of XCP and tried to improve the network and failed before.
-
But I only pursued it because I thought it could work.
-
The irony is the most successful Counterparty project skipped XCP. By design -
I truly appreciate the thought process of the founders. But is just not the reality. Users don’t want expensive XCP. They want it cheap and only needed for the minimum amount of actions
-
That is not ironic at all. That is the Tragedy of the Commons. According to the concept, should a number of people enjoy unfettered access to a finite, valuable resource such as a pasture, they will tend to over-use it, and may end up destroying its value altogether. Even if some users exercised voluntary restraint, the other users would merely supplant them, the predictable result being a tragedy for all.
-
Well it proves the token is not required for a project to be successful. And the protocol can handle free assets just the same as the ones that required XCP
-
The only issue with dispensers is that they are ordinary BTC transactions, without the cntrprty message. If we add the message, dispensers will be just as fine as the DEX. Is this correct or not?
-
Well that is the trade off for better UX. But in terms of performance, which is the main argument against them as far as I can understand, can be easily solved
-
Yeah is not perfect, but it works quite well actually (for users)
-
I guess I just don’t believe that more xcp fees leads to a better network, I’d prefer xcp liquidity to xcp utility -
how you do dispensers offchain? the good part and also the bad part is that the indexer is the one who writes the data into the db with just one tx if you do it offchain you will need 3 tx... -
im not aware of vennd sorry
-
will look for more info about
-
GitHub - vennd/vennd
Contribute to vennd/vennd development by creating an account on GitHub.
-
this one right?
-
Muted for being disruptive. Due to more than three warnings -
I'm not a dev like you guys
-
Is easy
-
Joined. -
Is easy for sellers and buyers. I’ll give you that the implementation was not the best. But it is solvable with minimal adjustments
-
Psbt marketplace fees is the lowest hanging fruit
-
Those could go direct to development
-
This is a funding solution
-
Funding development is key to a sustainable platform
-
Would having an order open without expiration be similar to the problem created by dispensers never closing?
-
Let's shelve this please
-
Not the time. Not the room
-
Sir isn’t this what we’ve been talking about
-
"talking about"
Getting off topic, with drama? Yes -
“How to sustain the platform”
-
Psbt marketplace fees are a concrete plan
-
Not a pressing issue currently
-
Do you have some examples that you feel are successfully doing this? Tbh, I just see a tragedy of the commons everywhere, including Bitcoin. -
Psbt isn’t how things work now. So it’s not very low fruit. And taking tx fee got devs of a dex arrested I think.
-
Too many people are trying to take logical shortcuts and shorting out the full picture
-
Speaking of tokenomics, word is that if xcp value rockets, then fees will scale to still be affordable. Is that dial-down part of the xcp as gas system?
-
☝️
-
When CounterParty is patched up good again, a culture of successful projects donating to core devs needs to be fostered.
Due to the state of things, historically many successful projects jumped chain after raising funds. Functioning in good working order should retain projects going forward 🤞 -
In general I don’t like the culture that comes from having a paid dev team. I would have wanted to be paid. Yet I’m not.
There are clear benefits to have a focused group of people working on a piece of software. And even more if is people familiar with it.
But it should not become a hierarchy where then these group will want to continue building features just to justify their payment.
TLDR: Dev team leads to centralization. -
We all generally agree on a couple of key points:
1º Counterparty definitely needs some focused attention from both developers and stakeholders to iron out the kinks and spark new innovations.
2º It’s crucial to make sure that the assets on Counterparty stay liquid and easy for everyone to access, steering clear of any unnecessary frictions.
Reflecting on the diverse viewpoints shared in this discussion, I understand the concerns about how a paid development team might shift the culture towards centralization. It's about finding that sweet spot where we can harness the expertise of developers without creating an unwanted hierarchy.
Establishing a bounty fund and incentivizing node contributions could stimulate development and promote a healthier market dynamic as they would add liquidity back to the market. hese incentives should encourage contributions from the wider community, sidestepping the need for a fixed, centralized dev team.
On the topic of enhancing the platform's native token, the ideal goal is to boost its utility and liquidity without complicating things for users. Ideally, we want a system where interacting with XCP isn't a hurdle but rather a seamless part of the experience, driven by demand from platforms that utilize XCP for various fees.
Action Plans:
For Development Incentivization: Instead of a traditional paid developer team, let’s create a bounty fund that rewards impactful contributions. Bounty creation should be community-driven, with proposals and votes cast using XCP tokens. Also, granting voting power to other Counterparty assets, albeit with lesser weight, acknowledges their value and involves the community in steering the platform’s future. This mechanism not only adds another layer of utility to the XCP token (and justification for the fee) and use of the network but also democratically involves our community in deciding the platform's development direction.
For Enhancing User Experience and Liquidity: Implementing user-friendly solutions like PSBT is key. While having a healthy market dynamics of people earning XCP and platforms needing it or users to vote. Alongside, efforts to get XCP listed on more exchanges and a strategic communication campaign could better position Counterparty externally. Welcoming new creators and projects will inject fresh energy, broadening the platform's appeal and functionality.
I think we are in a great point where we just have to find the common ground and declare options that will maintain us united and motivated for the future, we are all Counterparty. So all the viewpoints in this conversation will be the same of the community. -
Sorry for the long text, you can read at it in the bathroom lol
-
I´m not here for discussing, but more for gather all viewpoints as I see many valid motivations in each side that i´ve tried to gather after reading you all.
-
Joined. -
Oh my, 800 unread messages. The heated discussion is on XCP fee on utxo binding?
We have always had XCP fees on computationally expensive operations. Like on dividends since 2014. Ie xcp fee when the btc fee is not sufficient.
As far as i understand, utxo binding can be implement in several ways. Let's explore different implementations. Maybe a simple solution exists, so no need for an xcp fee? -
Could what i outlined on github work?
https://github.com/CounterpartyXCP/cips/discussions/134#discussioncomment-8369884PSBT Support via attaching assets to UTXOs · CounterpartyXCP/cips · Discussion #134CIP: XXX Title: PSBT Support via attaching assets to UTXOs Author: Derp Herpenstein Discussions-To: ?? Status: Draft Type: ?? Created: 2024-1-26 Definitions PSBT - Partially signed bitcoin transact...
-
stamps are expeced to track all utxos to ensure they not spent -
Wow what happened? 800 messages behind, lots to read.
We in this room understand the performance issues and barriers to entry regarding running an xcp node. Spinning up a new node and the node taking some time to index, verify, synchronize etc is not the end of the world, but good job with the performance gains.
As long as the final performance of counterpartylib/address index/counterblock is ultimately fast enough to keep up with new blocks, I don’t see the big stressors about performance. Launching a new node quickly and easily is not as important as the feature set. -
@krostue or @uanbtc please ban the 2-4 recent egirl thots from the chat.
-
I am just a Counterparty user who made a few stamps I am not involved economically nor am I involved in deployment ...
Keyburn the idea was open sourced, anyone is free to use or to not use it when making stamps
I am patiently waiting to see the spent prunable stamps distinguished from the unspent ones -
Can we do it without requiring utxo tracking?
We need three new message types then:
1. to bind token to utxo. Counterparty wont check if utxo exists
2. send from utxo to specified address (for psbt trading). Unlike all other counterparty messages, the input utxo is the implied initiator (not the address).
3. redeem to origin, valid only if utxo does not exist (safety mechanism in case of accidental utxo spend). This will require utxo tracking but only when this msg is detected. -
UTXO tracking be it for Stamps or for PSBTs means checking every input of every btc tx of every block
-
One exception is you can skip the coinbase tx inputs to speed things up
-
Not if you require a counterparty message
-
I could spend a asset containing utxo with no counterparty message n Counterparty would need to know else it will assume the utxo still contains a asset
same for stamps I could spend just one of the many outputs that makes a stamp and stamps needs to know as it then no longer fully utxo resident -
Bitcoin does this every block pretty efficiently
-
And that’s for all utxos not just those that explicitly hold counterparty assets
-
Runes does exactly this as well
-
yeah 'gettxout' is the rpc command
-
For the record, I’m not against xcp fees for any future counterparty smart contract / amm functionality, just don’t think it’s going to be an easy design choice to defend for utxo binding in the current bitcoin indexer environment
-
And after years of sucking it up wrt design choices I don’t have it in me to defend something I don’t agree with
-
Why?
-
you need to run that command for each and every data carrying vout in each and every stamp creation tx after each block, but you only need to run for the specific vouts when using for psbts
-
Joined. -
I'm not intending to be rhetorical. It is a genuine question
-
I suppose my point is that this should be addressed before the system is created so that it can it can be considered when being made.
For example. If one XCP gains the value of $1000 or more (for weeks or months on end), the fee to create a named asset should be scaled back to something like 0.05. Likewise if it costs ten XCP Satoshi to do things when XCP is in its current state, then there should be a way for the developer team to change the rate, down to one. That is to say, unless the fee can be dynamic based on value determined from on-chain trade history. Trustless salable fees would be the best possible case, imho -
I thought it was to be that xcp fees were determined from availavle xcp supply not its usd market rate
-
btc market rate makes more sense, but still
-
I understood / had the impression it was to become that as xcp supply decreased so did the xcp fee for a given action
-
yes atm but word was
-
there are multiple parties here, some people are part of both, but the majority of users seem to either want the price of XCP to go up, or the protocol to be as sound as possible. These two objectives are at odds with each other because they are interconnected as they opposite ends of the same stick.
This notion is to address the scalability of the project, not in technical ease of use, but to prevent it from being something only affluent people can use and hopefully keep the protocol more accessible to all by keeping it affordable.
I am not trying to convince anyone, just attempting to voice something that I feel is relevant before it is overlooked -
xcp is burnt so it's supply only decreases over time, xcp btc and or xcp usd price can move in multiple directions
-
i need to review/edit what I wrote, that is not what I intended to communicate. While it has in the past, I see no reason to believe that currently
-
two ends of the same stick comment, I was trying to illustrate that although it seems at times that the party who wants XCP price to rocket and the users who want a fully functional protocol lose sight that they are discussing the same topic. All too often a single sticking point divides the camps more, based on narrative. However, sacrifices of ideals will need to be made for this venn diagram to work.
This graphic fully convinced me.
in the conversation over the last day and a half there was a very valid problem of optics brought up. However, this can be overcome with education.
Myself, I am willing to dump dispensers, if that means that the protocol itself is stronger, and easier for people to spin up nodes. There are many interconnected variables, technically and socially, and I think it is difficult for the average user to have empathy for more than one camp.
AFAIK adding proportional fees to things that burden the network is pretty much accepted, as demonstrated by the recent poll antics. Last time the problem was the shortened fork notification.
What are the outcomes of eliminating dispensers and replacing them with something more sound? Possible fork? Again, back to education. Users will want to be part of a protocol without bugs, as it will have the best chance at longevity. -
I am sure my draft can be considerably improved. Just happy if this gets the snowball rolling.
And yea, this where a good xcp fee system becomes essential. -
Btw my draft is based on Devon Weller's from 2015'ish.
-
Doesn’t it need to ensure that utxos spent in a block existed to be spent?
-
that is understood. Even with the replacement, education is key.
Looking forward to what is coming. much appreciation everyone -
The only way a ‘fee’ sounds correct IMO is if the XCP fee can be seen by layer1 and layer1 can somehow rely on the XCP tx (hash?) for reference, adding true utility, besides on node calculations run by willing volunteers.
-
Fees are fine. I can’t park my boat there normally, but I can for a fee! (Parking ticket)
Give true utility and people will pay a fee. -
This. Volunteers, not miners receiving a cut of XCP.
-
Unless the fee tx includes real utility, this applies IMO.
-
Does it lag behind layer 1 after initial sync?
-
doesn't require much convincing anymore. https://slipstream.mara.com/
-
FYI, not really related but I saw some mention of roll-ups earlier, so here is a new partnership we've just announced: https://x.com/BVMnetwork/status/1762448715225170233?s=20Bitcoin Virtual Machine (@BVMnetwork) on X
The Data Validity layer from @Stampchain is now available on @BVMnetwork. With this integration, developers can now choose to roll up to Bitcoin as Stamps or Ordinal Inscriptions when setting up a new Bitcoin L2. What makes Bitcoin Stamps unique is its unprunable nature. Unlike…
-
Define valuable. In fiat or in utility?
-
Separate. It’s the team behind Bitcoin City which was a competitor to Friend.Tech
-
I’m not here for JPG slinging bag pumping. I have been here for years wondering if XCP can rise to the likes of Omni and allow me to use it for real world utility. Tag me when that becomes a possibility.
-
Tether doesn’t even use Omni anymore, right? What is running on Omni these days?
-
What is “real world utility”?
-
Real Estate deeds on the blockchain?
-
tether/omni is actually a great case study in how an indexer can become captured by a single successful project
-
Tether did not use Counterparty for almost a decade.
-
it never used counterparty
-
there is still tether on omni but i believe its slowly being phased out
-
Right
-
It used Omni
-
Anything besides tether?
-
You can mention Omni in a board room and show some examples of the ecosystem with DEI hires. Not so much with XCP.
-
Wasn’t it literally the same team behind Omni that started Tether. Craig Sellers? I think… I thought Omni was purpose-built for Tether rather than being “captured”
-
Fork?
-
omni hard forked to freeze stolen tether balance from bitfinex
-
-
still about $150mil tether on omni
-
it wasnt originally, i remember buying maidsafecoin on omni early on
-
the team may be the same but it wasnt marketed as a tether machine
-
i assume maidsafe is still in development 😆
-
i think it was bigger than the mastercoin raise
-
yeah def bigger, i remember it being a few million
-
-
i dumped that pretty quickly lol
-
Still waiting on my Mt. Gox payout!
-
Lets vote on it.
-
Bump
-
The vote thing was a joke re Middle of January. /s
-
Sending inline content is ‘t allowed in this group
-
Can we define the utility then?
-
Look carefully and you might find VC money in this chat.
-
xcpdev already has the broadcast issue fixed. If that one is your main concerns, it is an easy fix to apply and there will be no need to have an intermediate protocol version before v10
https://github.com/CNTRPRTY/counterparty-lib/commit/ab662e179d663d6873da96c3591be3fc6fadba12- Now if a broadcast has a malformed text, it gets rejected · CNTRPRTY/counterparty-lib@ab662e1(cherry picked from commit 6520fbddc3a36754e2376cf8dadd20ab2e4e55c5)
-
And I’m taking the time to read this stuff? Where are we? When are we?
-
Danger danger. True, but dangerous regarding liability and governance.
-
It’s technically a refried burn as XCP is burnt BTC.
-
Milestones, goalposts, terms and set deliverable dates could help mitigate runs on development.
-
You can’t leave the chat ever. We need you in here at all times please.
-
We should include all of JP J’s ideas. We always circle back to JP J anyways.
-
Your hegelian dialect is above all others! Congrats.
Thanks for sharing all your deep thoughts @chiefsockyaza -
its a lucrative business for magiceden, my point was just that there is an opportunity there, obvi it needs to be done the right way
-
That is a great way for dedicated devs to possibly pump their private bags and in return the devs could tithe their time back into the protocol. I would not recommend that idea protocol wide.
-
yeah i dont even know what “protocol wide” means in this context
-
there is no “xcp foundation” its just independent developers
-
“Those could go direct to development”
-
I am of the camp that a formal foundation is a bad thing.
-
yes it was a suggestion that developers working on development could build a profit making enterprise with
-
thus bringing in more developers, etc etc
-
We agree. I’m trying to keep (most) everyone out of jail.
-
My brain
-
https://hushmoney.org/501c3-problems.htm foundations introduce layers of issues.501c3: Problems with 501c3 tax-exempt status for the church
Are there any legal and theological problems associated with a church becoming an IRS 501c3 tax-exempt religious organization?
-
I’m only joining the foundation if the meetings are like this https://youtu.be/BKorP55AqvgThe Expert (Short Comedy Sketch)
Subscribe for more short comedy sketches & films: http://bit.ly/laurisb Buy Expert shirts & hoodies at https://laurisb.myshopify.com/ Funny business meeting illustrating how hard it is for an engineer to fit into the corporate world! Watch the next episodes: http://bit.ly/SquareProjectEp1, http://bit.ly/SquareProjectEp2 & http://bit.ly/SquareProjectEp3 Starring: Orion Lee, James Marlowe, Abdiel LeRoy, Ewa Wojcik, Tatjana Sendzimir. Subtitles available in many, many languages (enable them using the "Subtitles/Closed Captions" button). A big thank-you to everyone who translated! You can add new subtitles here: http://www.youtube.com/timedtext_video?v=BKorP55Aqvg Written & Directed by Lauris Beinerts Based on a short story "The Meeting" by Alexey Berezin Produced by Connor Snedecor & Lauris Beinerts Director of Photography: Matthew Riley Sound Recordist: Simon Oldham Production Designer: Karina Beinerte 1st Assistant Director: James Hanline Make-up Artist: Emily Russell Editor: Connor Snedecor Sound Designer: James Bryant Colourist: Janis Stals Animator: Benjamin Charles The original short story about drawing seven red lines "The Meeting" (in Russian): http://alex-aka-jj.livejournal.com/66984.html The Expert shirt campaign is over, but let me know if you'd be interested, you can check it here: https://bonfire.com/the-expert We made this video using: - Canon 7D camera: http://amzn.to/1FuXXVv - Final Cut Pro 7: http://amzn.to/1Lt7UrZ - Web-based Cyrillic converter: http://2cyr.com/ - The Hospital Club premises for a stage test (only partially recorded...): http://thehospitalclub.com/ - Libre Office Calc to make sense of the shot list... - 7 different markers and an empty juice pack to get the right sound - 7 red lines - A bottle of single malt whiskey Funny short comedy films / sketches / skits & any other videos / movies made by Lauris Beinerts. If you like to laugh, subscribe for new (albeit irregular) videos! Семь красных линий Гуманитарий и инженер Дизайнер и заказчик 工程师心里的痛只有工程师能懂 史上最悲催工程师 如何用透明笔画出红色线条 #ShortComedySketch #expert
-
the Bitcoin Foundation springs to mind
-
Classic lol
-
Release v9.61.2 · CounterpartyXCP/counterparty-lib
9.61.2 Release Notes This is a hotfix release: Fix integer overflow in dispensers. Invalidate broadcast with malformed text. Fix Logging for Destructions with Invalid Asset. Upgrade Commands fedn...
-
In my explorer, I can trigger a reorg back to a certain blockheight and it re-indexes from there. Do you think its worth re-indexing from a certain block with this hotfix?
-
kk
- 28 February 2024 (108 messages)
-
have this not sure if mean caught up -
DEBUG - applying 1 new headers from height 832391
DEBUG - downloading new block headers (832392 already indexed) from 00000000000000000001e138955ad6de6246a241d3a58d2a3bb5bc280025e384
INFO - best=00000000000000000001e138955ad6de6246a241d3a58d2a3bb5bc280025e384 height=832392 @ 2024-02-28T10:09:32Z (1 left to index)
INFO - indexing block 00000000000000000001e138955ad6de6246a241d3a58d2a3bb5bc280025e384
DEBUG - applying 1 new headers from height 832392 -
been busy past few days so have not been checking, I think it is good and I can start counterparty
-
Joined. -
should I run with Bootstrap or not
-
is has this is rm
-
counterparty-server bootstrap
counterparty-server start -
ya I just want to test
-
this will get nuked again
-
I meant I'm happy to test concensus if that would help
-
just doing cargo install maturin
-
then pip3
-
I'm lazily cloud hosting my fed node:
Google Cloud (c3-standard-4): 16GB / 1024GB Disk
It's $284/mo, but will get a little cheaper through sustained use discounts. -
idk im used to paying for servers
-
NUCs are fairly quiet. Make sure that SATA drive is SSD if you want performance and silence. If this is your first NUC, you may have to play with the BIOS settings (UEFI, FastBoot and RST) to install Linux, unless you are going with Windows.
-
@teysol and @robotlovecoffee Did I read correctly that you two (or anyone else) are not using docker for your counterparty node? Could you share any insight on running a fednode without docker? I could spin up a dev branch version sans docker and report back if that helps at all.
-
yes I'm doing this on an AWS instance, but just working to set it up. I'm new to this so just following the steps
-
in readme
-
GitHub - CounterpartyXCP/counterparty-lib at develop
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
Thank you very much
-
-
use this for your btcconfig
-
do not follow readme
-
for that part
-
sorry I assumed he just meant running a CP node
-
So fednode != counterparty-lib?
-
I did
-
I am not familiar with the nuance difference in a cp node and fednode. I assumed I needed a fednode and followed that rabbit hole previously.
-
I would much rather manually install without docker, even if it is more work or admin.
-
same I thought a fednode was just the term for the XCP stack running
-
Yup, and the readme for a fednode points to docs.counterparty.io
-
Yes, but only for the Fednode repo
-
Same
-
Thank you for the clarification. I will be spinning up a dev implementation soon.
-
Is it worth trying to install Counterblock or Counterwallet? I will wipe this and rebuild a few times for sure.
-
I’ve been syncing counterblock for like three weeks
-
I am still holding out hope for counterwallet, or an official protocol wallet.
-
I am willing to debug and help with counterblock if someone were to share the concerns. I remember it was mentioned about a month ago, but many topics were mentioned at that time.
-
I followed that, it's why I asked. Thanks.
-
Thanks for this info last month. Do you have insight into counterblocks status today? Where do we start for a fix?
-
Can you tail a log? Whats going on there?
-
It’s just taking its time
-
I put a timer on and it took 9m30s to progress 10 blocks.
-
Only one month out haha
- 29 February 2024 (64 messages)
-
Armory needed counterblock too, but armory is probably headed to the vaporware category.
-
Counterblock is broken, don’t run it.
I started working on it, but I had other priorities. And if the core protocol is undergoing so many changes, maybe is better to wait.
If someone else wants to work on it, go ahead -
getting he following errro trying to compile
-
error[E0308]: mismatched types
--> /home/ubuntu/.cargo/registry/src/index.crates.io-6f17d22bba15001f/maturin-1.4.0/src/upload.rs:398:40
|
398 | Ok(builder.tls_config(Arc::new(client_config)).build())
| -------- ^^^^^^^^^^^^^ expected rustls::client::client_conn::ClientConfig, found ClientConfig
| |
| arguments to this function are incorrect
|
= note: ClientConfig and rustls::client::client_conn::ClientConfig have similar names, but are actually distinct types
note: ClientConfig is defined in crate rustls
--> /home/ubuntu/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustls-0.21.10/src/client/client_conn.rs:128:1
|
128 | pub struct ClientConfig {
| ^^^^^^^^^^^^^^^^^^^^^^^
note: rustls::client::client_conn::ClientConfig is defined in crate rustls
--> /home/ubuntu/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustls-0.22.2/src/client/client_conn.rs:150:1
|
150 | pub struct ClientConfig {
| ^^^^^^^^^^^^^^^^^^^^^^^
= note: perhaps two different versions of crate rustls are being used?
note: associated function defined here
--> /build/rustc-QLyM7K/rustc-1.74.1+dfsg0ubuntu1~bpo0/library/alloc/src/sync.rs:385:12
For more information about this error, try rustc --explain E0308.
error: could not compile maturin (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile maturin v1.4.0, intermediate artifacts can be found at /tmp/cargo-installAwAYmO.
To reuse those artifacts with a future compilation, set the environment variable CARGO_TARGET_DIR to that path. -
running this step:
-
cargo install maturin
-
ya I ran this before
-
sudo apt install python3-pip
-
Python 3.10.12
-
python3 --version
-
I do not need to run unbuntu, just thought it was the easiest to stand up and run
-
deadsnakes does not sound good 🙂
-
ubuntu@ip-172-31-52-115:~$ python3.11 --version
Python 3.11.8
ubuntu@ip-172-31-52-115:~$ -
ok so go back and try compile?
-
ok will check back once it is done or pukes
-
just so you know guys! https://www.kucoin.com/announcement/en-stamp-stamp-gets-listed-on-kucoin
-
still getting this error
-
error[E0308]: mismatched types
--> /home/ubuntu/.cargo/registry/src/index.crates.io-6f17d22bba15001f/maturin-1.4.0/src/upload.rs:398:40
|
398 | Ok(builder.tls_config(Arc::new(client_config)).build())
| -------- ^^^^^^^^^^^^^ expected rustls::client::client_conn::ClientConfig, found ClientConfig
| |
| arguments to this function are incorrect
|
= note: ClientConfig and rustls::client::client_conn::ClientConfig have similar names, but are actually distinct types
note: ClientConfig is defined in crate rustls
--> /home/ubuntu/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustls-0.21.10/src/client/client_conn.rs:128:1
|
128 | pub struct ClientConfig {
| ^^^^^^^^^^^^^^^^^^^^^^^
note: rustls::client::client_conn::ClientConfig is defined in crate rustls
--> /home/ubuntu/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustls-0.22.2/src/client/client_conn.rs:150:1
|
150 | pub struct ClientConfig {
| ^^^^^^^^^^^^^^^^^^^^^^^
= note: perhaps two different versions of crate rustls are being used?
note: associated function defined here
--> /build/rustc-QLyM7K/rustc-1.74.1+dfsg0ubuntu1~bpo0/library/alloc/src/sync.rs:385:12
For more information about this error, try rustc --explain E0308.
error: could not compile maturin (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile maturin v1.4.0, intermediate artifacts can be found at /tmp/cargo-installtmufNw.
To reuse those artifacts with a future compilation, set the environment variable CARGO_TARGET_DIR to that path. -
These specs are for running mainnet and testnet at the same time?
Currently, for an mainnet-only instance 1TB and 8GB of ram works “fine” (not very stable, I have to reboot instances frequently. But I assume the code improvements will help in this.).
And then I am also interested in learning what will RocksDB be used for… -
Hard to tell because the fednode tail command don’t show any clear issue. Only with Bitcoin core which I have to delete the peers file sometimes.
But also I haven’t gotten deeper into it because rebooting works, so that is what I have been relying on. -
Ok so instead of addrsindexrs with its own DB, we will end up with counterparty-lib with 2 DBs, SQLite and RocksDB?
And then the RocksDB data will be supplemental, just to help in data that will end up in SQLite? Asking to understand if an explorer can continue only relying on the SQLite… -
Do you know if the current v9.61 already stores these automatically? If not, how can I get to these verbose logs you mention?
-
Cool. I think that having all consensus hashes affecting data in a single DB is something we should try to continue a much as possible
-
Yep I thought I saw this
-
Thanks will consider this
-
I’ll update to that, I don’t remember setting any config values like that
-
Full parse no bootstrap. And I think @XJA77 also is full parse
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)