- 07 November 2022 (7 messages)
-
What's the best way to test json?
Issue asset on testnet and see if it shows correctly on xchain?
Anything after ; is allowed but ignored? -
-
Ya try on testnet
-
Joined.
-
🙌🏿
-
This is where I need to be
-
Hey everyone, @onevsmany has a HipHopGame asset and is looking to build a hip hop game with Counterparty assets and a bunch of other ideas as well, so I invited him here as he gets to learning how to develop on/around Counterparty
- 08 November 2022 (70 messages)
-
-
Is price feed of PEPECASH/XCP determined by last dispenser sale? It seems that the price feed of PEPECASH isn't accurate and I believe it was caused by this dispenser:
https://xchain.io/tx/c0de56627728a9dbefb9c4a7500e64641389d822b5657a19f542deda27e9cd9d -
-
Can I join this chat? I’m interested in learning how to debug the parsing as I have been trying to sync nodes from scratch in both v9.60 and v9.59 without success
-
price on xchain is now taken primarily from the BTC price which is determined from the last dispenser sale or BTC sale on the DEX.... this is a more accurate estimate of price as ppl using dispensers to sell things for BTC way more often than XCP
-
It is DMs between Javier and I... if you want to follow the progress, you can do so on github at https://github.com/CounterpartyXCP/counterparty-lib/pull/1212/commits .... Not sure why your trying to do a full parse on 9.60.0 and 9.59 when I mentioned previously that a parse/full-parse would not work and Javier and I have been working on getting it fixed.... you canget up and parsing quickly by downloading the bootstrap image.protocol changes to get full parse / reparse working again by pataegrillo · Pull Request #1212 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
-
The fixes are in the PR.... and the fixes are beign "fixed" by adding protocol_change when there should have been some.... some tweaks were made in the past that should have been protocol changes, but were rolled out to production without a protocol change.... works fine when only going forward, but on a reparse some older txs are not parsed properly, resulting in a different ledger.... Javier and I have been doing parses, comparing the ledgers, finding differences, tracking the difference backwards to the problem, adding more protocol changes, doing another full parse, etc. I believe we are down to just one difference now that Javier is fixing this AM and then we are going to the full parse one more time
-
good news is we dug into the parsing a bit and found a big bottleneck with a couple of the dispenser indexes in the CP database, which was really slowing down block parsing... block parsing dropped from like 30+ seconds down to just a few seconds 🙂
-
painstaking work, thanks to you and Javier for doing it!
I appreciate the process explanations as well -
-
I see, but the issue with this is the price feed isn't accurate. It currently shows PEPECASH @"usd": "9.68683000", when it's roughly around 0.001$. This was caused by one dispenser.
-
I don't know how the price feed behaved before but I don't recall it behaving this way
-
price before was always taken from last XCP DEX trade price... which is not a very accurate way to do things... but it was all we had at the time...now we have dispensers getting way more use than XCP DEX orders, so seems more appropriate to price more accurately based off last sale for BTC
-
Strange.. i'll dig into this in a bit and see whats going on
-
This was caused by this dispenser:
https://xchain.io/tx/c0de56627728a9dbefb9c4a7500e64641389d822b5657a19f542deda27e9cd9d -
Someone dispensed many stuff including 1 PEPECASH and it affected the price feed
-
ahh... I see
-
my code is correctly determining the price
-
right
-
but... it isn't taking into account if there were multiple dispenses
-
Is it possible to include some sort of average?
-
will work on fixing that later today... to ignore price calculations from dispenses that trigger multiple dispeners..... since the price is related to buying ALL of the cards, not just a single one
-
not accurately..... best to just ignore and only take price from DEX trades and single dispenses
-
aaah that's what blew up the PEPECASH price :)
-
if your asking about average for multiple dispensers... my answer is above... if your asking about average price between BTC and XCP... I don't want to do that as it will confuse things even further... I want ppl to be able to look at BTC price and multiply it by supply and get marketcap 🙂
-
I can't think of a solution off the top of my head but I believe there needs to be a way to smooth the price so it doesn't jump around
-
marketcap will be based off BTC (most accurate price) and XCP price will be available to view, but not used to calculate marketcap unless there is not previous BTC price..... price shouldn't jump around much once I fix the issue you pointed out with dispenses from multiple dispensers.
-
will the new info/calculations available on the a xchain api?
-
they already are
-
-
-
I updated the /api/asset/XXXXXX api call to include "market info" with last/floor prices for BTC and XCP
-
I suggested a moving average of recent Dex sales a few years back but I recognise that’s a lot of effort relative to feature criticality
-
api documentation to follow?
-
also updated estimated_value to be more accurate since it is now based off last BTC price... not XCP price converted to BTC converted to USD (inaccurate)
-
Yeah that's what I was thinking
-
haven't got around to update the API docs yet... but no new api endpoints... just some more data on the already existing endpoint
-
np
-
dope work
-
perhaps in the next explorer.... trying to wrap things up with xchain so I can move on to the new explorer 🙂
-
-
Oooo a new explorer I see! sounds promising
-
I have such a basic question that I feel embarrassed to ask but this seems like the only place I could ask
-
got to start where you are at ;)
-
I'm pretty limited when it comes to coding / protocols too, so I am here to learn from everyone and all questions
-
This is so basic, I doubt it even qualifies as coding yet.. just thinking through my NFT release so I can code it later
-
I came across this website in 2000 as I was launching my first online hip hop community and the guy basically had 1 million pixels on his website which he sold for $1 each http://milliondollarhomepage.com/The Million Dollar Homepage - Own a piece of internet history!
The website of Alex Tew, a 21-year-old entrepreneur, who hopes to pay his way through university by selling 1 million pixels of internet ad space for $1 each.
-
The million pixels were sold in 10x10 blocks so the cheapest buy was $100 and there were 10,000 plots of land available.
-
My project is called HIPHOP.GAME. The game world is HIPHOP.COUNTRY. The country is made of 1 million plots of land. The smallest plot you can acquire is a 10x10 piece of land which gives us 10,000 NFTs containing (100 points). These are the NFTs that represent those 10,000 pieces of HIPHOP.COUNTRY https://xchain.io/asset/HIPHOPGAME
-
Next I plan to launch a new trading card for each artist that becomes.a character minted into the HIPHOP.GAME's metaverse. Each new artist will mint 10,000 cards that each correspond with 1 of the 10,000 pieces of land
-
My question is
-
1) Is there a built in way to track the NFT item IDs within the 1-1,000 or do I have to number the cards 1-1,000 in the metadata
-
Counterparty assets are not uniquely serialised
So you will need to create your own serialisation system and tracking them as they trade hands would be problematic. -
Problematic how? Aren't they just items in a wallet? Addresses connected with addresses?
-
let's deal with any technical elements here, but not so much any discussion of game mechanics or your own platform needs
-
Understood
-
for scenarios not specifically related to protocol dev and app integrations, probably better off discussing it in https://t.me/Counterparty_XCPOfficial Counterparty Chat
Website — https://counterparty.io Docs — https://docs.counterparty.io GitHub — https://github.com/CounterpartyXCP/counterparty-core Twitter — @CounterpartyXCP
-
Okay I understand
-
I'm also happy to continue the discussion in @WTHAuctionHouse
-
This is just for counterparty core development not developing counterparty projects
-
I misunderstood
-
Thanks!
-
I think here is only for when you're developing your app and you need support with interacting with the protocol on a dev/app level
-
Counterparty is simple, whatever you want to “track” or update should be an asset (named as you wish, including subassets by adding numbers)
Then these assets have units / quantity of how many “tokens” you want the asset to have. These tokens are fungible within the same asset, no way to differentiate between them -
FYI there has been some discussions in the past about how to best add serialized token functionality.... but no real consensus has been reached on if it is a good idea, needed, and how to best implement..... https://counterpartytalk.org/t/serialized-tokens/3486 ... Honestly probably best implemented in a VMSerialized Tokens
There have been a few conversations in the past on slack about serialized tokens and how they could be accomplished. Unfortunately, all of that conversation history is lost. I think it is time to capture this idea in a forum post and get feedback from the community. The general idea is to be able to assign each token a unique ID which is tracked through the tokens lifecycle. Example Use Joe the artist creates a new piece of artwork called “DigitalCurrency”. Joe now wants to sell the ‘origina...
-
quentin did this for the nakamoto club
-
you basically just need to develop a method that accounts for balances of multiple tokens, either LIFO or FIFO, then get people to buy in
-
This issue has been fixed... https://github.com/jdogresorg/counterparty2mysql/commit/fd06a20c0dba3d918e343e57f356b10ebc3f4afb
-
Great! Appreciate the fast response
- 10 November 2022 (5 messages)
-
-
I think I saw @robotlovecoffee had recently set one up
-
I had the cp2mysql working, have not gone fed node yet
-
just brought up a LAMP and working with that for now
-
Once my shop/office is setup I think I will look to get a node running
- 11 November 2022 (48 messages)
-
But you already got a node running? I’ve not used cp2mysql, but it requires a node correct?
-
Some thoughts on making dispensers safer. This is a market solution, no protocol update needed.
https://counterpartytalk.org/t/trusted-dispenser-dao/6454
The "DAO" will help with decentralization - if every key holder runs their own node. Fees can potentially be collected for a good cause, like XCP dev.Trusted Dispenser "DAO"Here’s an idea for making dispensers safer; “trusted operator”. No protocol update needed*. Possibility for the the trusted operator to earn a profit. Unknown / not trusted seller can put up a trusted dispenser. Buyer can be confident they’ll get their BTC back if dispense fails. The operator provides a long list of unused addresses. A seller can put up a dispenser on any of these addresses. Xchain / buyer can verify that dispenser is controlled by the trusted operator (even if the actual se...
-
It does not, it just calls the api to get each block and then calls to insert data.
-
-
you can use the public APIs and confirgure them in the config
-
-
-
-
Run your own node if you for some reason do not want to trust or rely on xchain. https://xchain.io/api
-
I do, and I’m continuing in v9.59 because I don’t agree with the changes in v9.60. And I recommend everyone to also be very careful with trusting. Bitcoin ethos is don’t trust, verify.
-
And I also continue in v9.60 because I just have not been able to get it to work. Has anyone been able to get a v9.60 node running?
-
have you asked @AryanJab ?
-
Please don't.
-
hahaha
-
i guess i need to fire up a node myself
-
I have a v9.60 node running .. its syncd to the tip block 762712
-
did you use the docker to install?
-
-
-
-
Related to rust?
-
this
-
I thought your name was familiar. Good luck with that.
-
this was the fix I used
-
this file was tweaked with the updated rust version
-
-
-
Thank you! I believe v9.59 is a more pure version of Counterparty than v9.60
-
-
-
-
Must it?
-
-
-
what's that?
-
The measure of its purity.
-
-
-
-
This is confusing 😂
-
Agreed.
-
-
-
Welcome bench! Glad ur here bro👍🏻
-
-
But that would make it NOT a protocol…
-
I should have said protocol updates, true
-
- 12 November 2022 (13 messages)
-
No dev related but wanted to see if someone can give this a sanity check, it is what I did as seemed to work but do not want to lead people wrong
-
-
6mins vid to use Electrum to get sats from wallets
-
It looks good to me. nice work👍🏻
-
and I right that both work the same and one would be just an extra step to a degree
-
Joined.
-
-
Joined.
-
Joined.
-
-
Joined.
-
Joined.
-
yes I saw that and posted below that it was visible, this was a dead account but I wanted people to know that they should be careful with them, I just did not want to delete, edit and repost the tweet. Thanks for calling it out.
- 13 November 2022 (3 messages)
-
Joined.
-
Joined.
-
- 14 November 2022 (90 messages)
-
Icons dont show on testnet xchain for DUCK, DUCKY, DUCKX. Been several days already. I used CIP25 json format.
-
Will it work on mainnet xchain?
-
-
i wonder if the linebreak after the name element is causing an issue
-
Shouldn't matter.
If json were invalid, standard image wouldn't show either. -
https://xchain.io/api#network
What is the difference between min_relay_fee ? and Optimal or low_priority?
I assume its not an additional fee, and that its just the min fee that wont be rejected / bare min fee ? Think im getting hung up on the word "relay". -
-
Try making sure your add a "Access-Control-Allow-Origin:* " to your server so that the file can be requested remotely by end-users... right now remote browsers cant get your JSON
-
lmk when that is fixed and i'll take a deeper dive into why your icon isn't displaying on testnet xchain.
-
min_relay_fee is set by each BTC node operator... so this varies between nodes... this is why I dont ever try to go "too low" on fees or the network will ignore the tx.
-
the low fee is high enough to get relayed but low priority.... high fee is high fee to get processed in next couple blocks.... I take the fee info directly from mempool.space API https://mempool.space/api/v1/fees/recommended
-
ok cool was just checking that min_relay_fee wasnt an additional fee i needed to include i will just use optimal tyvm
-
Access-Control-Allow-Origin * header added to htaccess 🤞
-
-
??? Not sure I follow... or if your trying to be sarcastic... I have never removed you from any channels, not spoken negatively of you, and I have gone out of my way to calmly explain the current CP development process, answered any questions you have had, etc. I am not sure why you have taken a position that I am trying to control Counterparty or the community, as that could not be farther from the truth. I have been here supporting Counterparty for many years and I will continue to do so. My hope is that as you spend more time around the CP community, you get more familiar with the history and current state of things, and perhaps your viewpoint will change. In either case, your more than welcome to stay in this channel and discuss CP dev and such, provided your not advocating for people to run your fork and railing agaist the current 9.60 version... that ship has sailed.
-
I was let back in the other chat, but got kicked out for a moment
-
-
-
I tend to take a hands off approach to adminning channels in most cases... so, I can guarantee you that I have not removed you from any channels.... nothing you have said has warranted it thus far... your just advocating for your beliefs, which is fine.... tho you cross the line when you advocate for a fork, so I respectfully have asked you to refrain after hearing you talk about your 9.59 fork for many weeks now.
-
Juan, we have already gone over this multiple times.. all code is done on github, all testing notes are in github issues, 9.60 was reviewed and tested by Javier and I for well over a month before release, and anyone who wanted to participate was more than welcome to do so. Stop trying to spin the narrative that secretive things are going on in dev, as that is not the case, everything is public on github!
-
-
-
Again, you were not ignored, you were in the minority opinion
-
-
-
Funny thing is I never claimed to be the leader of CP, nor do I want the position.... I'm just the dude who has been running stuff and supporting CP for years... and who the founders handed the keys to when they left the project... I am no leader, just a normal community member who happens to have repo access.
-
Wow
-
-
I’m asking code reviewers
-
Had you been around through the years, you would see this... but you have just arrived, seen that the community respects me, seen a change you dont like and where the community disagreed with you, and you have unfortunately spun it into some narrative that I am trying to control CP.... had you been around for a while, or taken the time to actually ASK some community members who have been around for years, they would tell you..... instead, you show up, tell us how things should be, and when we disagree with you, you loudly scream foul, and then consistently change the narrative to try and get more attention, at first it was "CIP3 is bad".... but that didn't gain much traction, so now you have pivoted to "Multiple CIPs in a release and not doing full parse is bad" and hoping that helps you out to gain community support.
-
I truly wish you did not see me as some enemy, but unfortunately that is the viewpoint you have at this time, which is sad. My door is always open should you ever want to talk (tho through all of this, you have never showed any interest in getting to know me or my character, as you have never sent me a single DM.... just make judgement calls on my behavior without knowing my character.
-
No. I don’t see you as an enemy.
And I respect the dedication you have.
I just truly believe that me challenging will only improve the state of the project.
If me keeping a node is really going to disrupt the project, then it deserves to be disrupted. This needs to happen for the long term strength of the project -
I actually have. And email
-
Differing voices in a project definitely help make the project stronger. When those disagreements spill over into the general community and cause division, that is not good/acceptable.
-
And your responded! And that was great!
-
I think you’ll find if you go into any other blockchain chats and tell users not to upgrade you would be booted much quicker than what you’ve experienced here
-
I respect your viewpoint that CIP3 is bad, tho I disagree, and if you decide to continue with your fork, I will do what I can to answer any technical questions you have, etc.... but, I will not tolerate advocating for a fork in the main CP channel, if you want a fork, it is your job to setup the fork and advocate for people to join your project through your own communication channels.
-
Even if they raise serious concerns? You’re perspective is to blindly trust the repo it seems…
-
You’re entitled to your opinions
-
You blindly trust the repo or you review it?
-
I don’t personally review every code change if that’s what you’re asking
-
-
But your “smartest guy in the room” act is not helpful to discourse
-
Do you blindly trust the Bitcoin repo or do you review every change?
-
It’s amazing counterparty survived for 8 yrs before Juan showed up to fix it
-
your argument is a philosophical one, there isn’t really any middle ground
-
-
It kind didn't. Cannot parse without bootstrap, right? Which Juan pointed out and Jdog/Javier are fixing
-
Exactly but that’s a 9.59 problem too
-
This is where Juan’s argument breaks down
-
He arbitrarily chose the version that was here when he got here
-
As the true version that shall not fork
-
-
Not arbitrary at all, I’ve only ADDED the parsing as one MORE problem (and a huge one) for the release
-
Im against destruction. .95 is my version
-
When in fact all protocol changes are forks, this is how we have enhanced send, dispensers, p2sh message encoding
-
Etc
-
correct... last reparse was triggered in 9.59.0.... 9.59.1-9.59.6 had updates which did not trigger a reparse.... in testing 9.60.0 for release, Javier and I discovered that the reparse/full parse was broken and have been working for the past month to find/fix the parsing inconsistencies.... very close to having it fixed, prolly later this week.... can follow the progress at https://github.com/CounterpartyXCP/counterparty-lib/pull/1212protocol changes to get full parse / reparse working again by pataegrillo · Pull Request #1212 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
The release is done, it cannot be rolled back, you would roll back assets issued since then and xcp balances etc?
-
Only one right
-
Promoting 9.59 is an attack at this point
-
My dedication to CP is unwaivering.... but not gonna lie, have had some thoughts in recent months how much easier life would be if I could just build NFT projects and ideas I have versus maintaining the CP infrastructure..... but, dont have fear, i'm here for the long haul 🙂
-
I’m very disappointed at you man
-
You just don’t understand what it is you’re actually doing by promoting a minority fork
-
appreciate you ser many of us support your tireless efforts maintaining this community
-
I don’t know how else I can explain the destructiveness of that action
-
Nope, I’m helping make Counterparty stronger
-
You can not like it and propose changes going forward
-
But you cannot rollback
-
Exactly, you don’t understand
-
You don’t understand Bitcoin. If me keeping a node is a serious threat to Counterparty, it deserves it
-
Your node is your node
-
-
-
Lol what is your node?
-
you keeping a node is fine... calling it "Counterparty" and telling people to run your version is confusing people... and yeah, at this point, we have been patient enough... it is an attack.
-
Juan is on timeout
-
if we are having a serious conversation based on evidence, then i would like to ask if your concern was voiced on github before the upgrade
-
if we are having a serious conversation, I would like to ask if you reported your concern about freewallet "security issues" in a github issue so that the issue could be reviewed by devs? .... as clearly you have some concerns, which are not documented on github.
-
cuts both ways bro
-
-
what known issues? Nothing has been reported on github, where issues are reported.
-
That’s how open source works
-
Perhaps you should consider writing up your concerns into an actual github issue..... rather than just sending DMs to people to try and scare them, and having private chat rooms where you rail against freewallet, and kick anyone who has a differing opinion
-
find a bug... report it... it gets investigated, notes are made, and it gets explained or fixed... this is the normal software dev process
-
-
Glad you understand... so, if you truly have security concerns, I can expect them to be documented in an issue going forward... thanks https://github.com/jdogresorg/freewallet-desktop/issuesIssues · jdogresorg/freewallet-desktop
Desktop wallet for Win/Mac/Linux which supports Bitcoin and Counterparty - Issues · jdogresorg/freewallet-desktop
-
-
games? I am simply asking that software issues be reported to the developers, seems like a pretty simple request if you want issues to actually be investigated and fixed.... unfortunately, I can't know what is in your head until you document it in an issue.
-
Duncan on timeout
- 16 November 2022 (6 messages)
-
I fixed cross-origin but icons still dont show on testnet xchain for DUCK, DUCKX, DUCKZ, DUCKO
-
Should be fixed now... https://testnet.xchain.io/asset/DUCK ... Issue was I was only paying attention to "image" in the JSON and not detecting icons using the "images" array.... now if you specify an icon in the images array only, it works as expected and displays the icon 🙂
-
-
DUCK wasn’t registered until 7 days ago???
-
Oh sorry testnet link
-
yeah... tons of amazing asset names on testnet still 😛
- 17 November 2022 (23 messages)
-
Hey guys,
Does anyone know how xchain circumvents the 1000 limit for the get_{table} API function ?
I'm also wondering why is there a limit in the first place ? -
Neither xchain nor CP API allow you to request more than 1000 records in a single request.... you can page through the results tho to get all data with additional requests
-
-
-
I stand corrected... looks like you can dump all data from a table using the CP API by specifying limit: 0 ..... if the node supports it.
-
is this why the mobile wallet wont let me scroll passed F in the alphabet lol!
-
i know the mobile wallet is no longer supported just wondering if this was the case
-
I think mobile wallet has an issue where it only loads the first 500 assets... .not a problem for most 😛 freewallet-desktop is up to date and should paginate through your balances to load/display all of them
-
freewallet-mobile hasn't been updated in a number of years... just the basics work (issue / send)
-
oh interesting, i'll try.
Also, i'm aware with xchain API limitation too. But how does xchain itself display more than 1K elements.
See mempool for example: -
Isn't xchain also using the CP API?
-
the CP API uses sqlite internally... which is not exactly a fast database... definitely not something you could/should try to run a block explorer from.... Matthew Tan did that with blockscan.com for a while, but it ran really slow....
-
Xchain uses a mysql database..... I use counterparty2mysql to pull all data out of the CP database using the CP API (messages table), and then I populate that same data into a mysql database with some optimizations (indexed all addresses, assets, addresses, etc) https://github.com/jdogresorg/counterparty2mysqlGitHub - jdogresorg/counterparty2mysql: PHP script that populates a MySQL database with Counterparty data
PHP script that populates a MySQL database with Counterparty data - jdogresorg/counterparty2mysql
-
so.... xchain is driven by the mysql database.... not requests to the CP API.... the one exception is the mempool/pending txs.... that data comes directly from the CP API
-
Ahaa, that's good to know. I was under the impression xchain requests all data from CP API. Is this the reason why xchain processes mempool data much faster than my node?
So, regarding the mempool limit. Are xchain GET requests for the mempool data specified with "0" to get unlimited elements? -
(If I understood right, xchain faces the same limitations since it requests the mempool from CP API)
-
I just do normal requests to the CP API... I don't dump all of mempool... just the first 1000 records, then need to make additional requests for data beyond the first 1000
-
Ohh gotcha!
So I need to implement some sort of a conditional statement if the records hit 1000 to make another request with an offset -
counterparty-hw/lib/fetch.js at rpw · loon3/counterparty-hw
Counterparty wallet for use with Ledger Nano S / S Plus / X - loon3/counterparty-hw
-
here’s an example in js using promise
-
thats for xchain, i can give you a php example for querying direct from cp api
-
whats free wallet mobile written in btw?
-
sencha touch
- 18 November 2022 (10 messages)
-
Is anyone experiencing issues with CP node?
Mine keeps falling out of sync . and it seems that xchain is also being slow.
Is this related to the 1500's unconfirmed transactions being stuck since yesterday?
Those issues started as soon as those transactions were submitted . -
yes CP is running a little bit slow due to the mempool being so full/busy.... how CP deals with the mempool updates it is deletes everything from the mempool database table, then re-create records for all pending txs, normally we do this every second or so when mempool is mostly empty... but, as mempool gets busy, the frequency with which we update the mempool drops off a bit to allow CP to spend its CPU cycles actually processing blocks/transactions rather than wasting CPU cycles constantly deleting and recreating mempool records.
-
Good news is
-
1.) the mempool will empty out in the next few days
-
2.) Javier and I have made some database optimizations which speed up parsing considerably... so after we get the parse/repare stuff fixed (doing full parse on api1 now), we should be able to put out a 9.60.1 release which has the parse/reparse stuff working again as well as a major speed improvement to parsing
-
Block parsing on 9.60.0
counterparty_1 | [2022-11-16 18:27:11][INFO] Block: 763459 (154.32s, hashes: L:56e88 / TX:17994 / M:8f86b)
counterparty_1 | [2022-11-16 18:43:36][INFO] Block: 763460 (226.50s, hashes: L:19a53 / TX:50edf / M:e5a1f)
counterparty_1 | [2022-11-16 18:47:59][INFO] Block: 763461 (105.56s, hashes: L:7095b / TX:5e68e / M:622ec)
counterparty_1 | [2022-11-16 18:48:37][INFO] Block: 763462 (37.83s, hashes: L:0225d / TX:8f0e3 / M:09270)
counterparty_1 | [2022-11-16 18:48:58][INFO] Block: 763463 (21.57s, hashes: L:b86fd / TX:b1d0d / M:0b203)
Block parsing after 9.60.1 parsing fixes
counterparty_1 | [2022-11-16 19:10:14][INFO] Block: 430590 (1.17s, hashes: L:aa405 / TX:c4f8b / M:83e2c)
counterparty_1 | [2022-11-16 19:10:15][INFO] Block: 430591 (1.02s, hashes: L:5c81d / TX:55620 / M:7fe4c)
counterparty_1 | [2022-11-16 19:10:15][INFO] Block: 430592 (0.20s, hashes: L:7765d / TX:67c39 / M:e3eb5)
counterparty_1 | [2022-11-16 19:10:16][INFO] Block: 430593 (1.17s, hashes: L:0584b / TX:b656f / M:e6711)
counterparty_1 | [2022-11-16 19:10:17][INFO] Block: 430594 (0.23s, hashes: L:310fe / TX:1e761 / M:5edfc) -
as you can see, parsing is considerably faster.... from many minutes to parse a block down to seconds 🙂
-
cp mempool handling would be a good project for someone not jdog and javier to work on, there’s probly a way more efficient way to do it
-
Always good to learn the inner workings of CP, Thanks for the explanation !
-
great news 🙏🏼
- 22 November 2022 (28 messages)
-
-
GM
Announcing: Decentralizing CNTRPRTY (cntrprty.org)
For a healthy competition of Counterparty development. All open source. No Blackbox. Free as in Libre. -
https://www.xcp.dev takes you directly to a mempool view! Is still in v9.59 though
-
can you discuss how these are simply tools and not a protocol fork
-
Is ALPHA software, my v9.60 node is still syncing
-
not sure if you can see old messages but parsing fix is nearing completion
-
Sure, the repo is just 2 web applications. One is a fully open source data explorer. The other is a version of bitSTART that has become open source
-
FYI: I agree that after weeks from activation, suggesting WRITING in an older protocol version can be considered an attack.
That has never been my intention. I was just mad and in the heat of the moment.
Let’s make the next protocol update the best one. And I hope we can improve some past implementations. -
Agreed. Disagreements happen in any family… what matters is we all love Counterparty and want the best for it. Let’s move past it and focus on moving this awesome platform forward together😀👍🏻
-
Yes there is a way, there is an undocumented sql api call!
https://github.com/CounterpartyXCP/counterparty-lib/blob/d7d739caed4a54f990624021643095b75f473ed9/counterpartylib/lib/api.py#L557counterparty-lib/api.py at d7d739caed4a54f990624021643095b75f473ed9 · CounterpartyXCP/counterparty-libCounterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
-
Thanks Juan! I'll check it out!
-
what was the slowdown in a nutshell? before is pretty damn slow
-
was an indexing conflict
-
not sure if jdog explained in here
-
protocol changes to get full parse / reparse working again by pataegrillo · Pull Request #1212 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
Yes, it was a very silly issue... a sqlite index being named the same thing on multiple tables, which was causing the sql queries related to dispensers take WAY longer than they should have
-
That simple adjustment of renaming the indexes on the dispensers table fixed the slow parsing and speed things up considerably... thanks to @pataegrillo for tracking down the parsing slowness issues and figuring out where the bottleneck was
-
almost every index have the same problem. The dispensers one was the only fixed, but we have to change the name of the others. Of course, this means a bigger database so we have to evaluate it first
-
Disk space is cheap, people’s time (syncing) is not. I would 100% do the optimizations.
Like Bitcoin, I believe the time is past to prioritize nodes. We need many nodes.
Competition and peer review of implementations. Only the best are integrated into the protocol. -
I totally agree, in our times disk space is not so relevant for this kind of server
-
One cool thing with the new issuance update is you can fit an entire ipfs cid into an asset description with opreturn
-
-
FYI... just created a pull request for CIP25 to add support for ipfs: urls which point to JSON .... https://github.com/CounterpartyXCP/cips/pull/64added support for IPFS format by jdogresorg · Pull Request #64 · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Also updated xchain.io to support this new ipfs: format ... https://host1.xchain.io/asset/BARRYPOPPINS
-
Thx to @hodlencoinfield for coming up with the format which fits nicely in a single OP_RETURN 🙂
-
case matters or no? IPFS or ipfs
-
case doesn't matter in my parsing... /^ipfs:/i .... you can use IPFS: or ipfs: or IpFs: :)
- 23 November 2022 (35 messages)
-
I like lower case, so thats what I put in the CIP PR... but, any case works 🙂
-
ok cool
-
what are the nominal sizes for the different image types "standard", "large", "hires"
-
no set sizes.. tho you can specify the dimensions with the "size" param... "size": "400x560"
-
on xchain I just display the image at its natural dimensions, so no need to specify... but you can if you want to 🙂
-
got it
-
-
example using ipfs prefix
-
I’m not the biggest fan of ipfs (find it overly complex), but this is much better than the links that some are already broken
-
its probly the best option out there that doesnt require a token
-
-
hashing AND its addressable
-
thats the big difference
-
end of the day images probly need to be cached, nice thing about ipfs is that theoretically the asset issuer could spin up an ipfs server and the CID would be the same and the content would be available
-
-
the CID is the same no matter what IPFS server hosts the file
-
your IPFS server would need to be connected to a peer that has the file, just like a torrent
-
the CID replaces the torrent file and infohash
-
and its “tracker-less”
-
-
Like this
-
the problem i think is that people think of it as a sort of panacea rather than just accepting it for what it is
-
a content addressable torrent system
-
which is cool as long as you understand that data only persists if its popular
-
everyone understands that in the world of torrents
-
I think NFT owners have the most incentive to ensure the future existence of the art tied to their token. So as long as a hash persists they can always “prove” the relationship to a piece of art even if it sits on a thumb drive for 20 years and is gone from every other server
-
Would be nice if the wallets automated this to some degree. Like an offline library of images on your device
-
agreed, wallets in general could do more to preserve token media and metadata
-
But I would take it one step further than just having a hidden image cache folder somewhere. It should be surfaced in a way like a checkmark ✅ next to your NFT in your wallet so the user has a better understanding and appreciation for the linkage and that the hash resolves to the image. Maybe most people don’t care, but think it would be cool.
-
Tough to do with web app wallets, could def do with desktop app
-
Clubnft.com is working on integrating with wallets to provide a “backup” service
-
I made a backup of all counterparty asset images.
https://jpjanssen.com/xcp-archive/
Next time i run the script it will look for onchsin hash proof too. -
https://xchain.io/tx/2062284
i broadcast a hash of the entire archive. The hash is of a csv that contains all image hashes. Wallets/explorers csn use this to in case of dead urls.
I can share a zip of the archive to anyone interested. -
ipfs format looks elegant! I like how it fits opreturn.
Is it documented how i would get to the data from the ipfs hash, and 2) how to verify it. -
You just check the asset’s descriptions for a matching hash?
- 27 November 2022 (9 messages)
-
Joined.
-
Joined.
-
-
Joined.
-
Hello Counterparty devs 👋
@SamixDotEth and I are devs who are looking into contributing and building on top of Counterparty.
We've been in the space for a while now and have been building in the Ethereum ecosystem. We're firm believers of Bitcoin and it's only fair to do our part, add value and bring visibility to Bitcoin as well and we feel that Counterparty is the way to go.
To better understand Counterparty Protocol we thought that it would be beneficial to help out the Counterparty team with revamping the docs. Let us know if this is of interest to you and we can further expand on our idea. -
Welcome. Glad to have u as a part of the CP community.
Fyi, we recently updated our documentation with a new site at docs.counterparty.io -
This is exactly what we were thinking of, revamping it using Docusaurus. Hehehe ☺️
If you need any help in the future with it we would be happy to help. -
🚨🚨ANNOUNCEMENT🚨🚨
GM Developers,
Ready to publicise your skills? Want to collaborate with others in the Counterparty community? Well have I got the Google Form for you…
Fill in this form and you'll be added to the Counterparty Developers Register. The register will be publicly available and shared regularly in the Counterparty Telegram groups to allow potential collaborators to match with developers.
https://forms.gle/An5npxWAzJZ5dvy59
Thanks for your time. 🙏Counterparty Developer InfoAre you a developer with skills in Counterparty amongst other things? Complete this form and we'll add you to the register of Counterparty Developers that will be publicly available via the Telegram Counterparty chat groups (https://t.me/Counterparty_XCP and https://t.me/Counterparty_Dev) We'll periodically check in with you to see if you are still available / interested.
-
None
- 28 November 2022 (4 messages)
-
-
Think still not working
-
Wait really?
-
Haha I already did it
- 29 November 2022 (82 messages)
-
protocol changes to get full parse / reparse working again by pataegrillo · Pull Request #1212 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
FYI... parse/reparse fixes are complete.... updating the servers now... will wrap up these changes and a couple other minor tweaks (bitcoin version bump to 24.0 and database integrity check optimizations) into a 9.60.1 release in another few days. 🙂
-
bitcoin version bump PR = https://github.com/CounterpartyXCP/federatednode/pull/337Bump Bitcoin Core version to 24.0 by jdogresorg · Pull Request #337 · CounterpartyXCP/federatednode
Federated Node Build System. Contribute to CounterpartyXCP/federatednode development by creating an account on GitHub.
-
database integrity check PR = https://github.com/CounterpartyXCP/counterparty-lib/pull/1213Db integrity check changes by pataegrillo · Pull Request #1213 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
I also just updated the main CP mainnet and testnet bootstrap...
Users can do a reparse by running fednode reparse counterparty to verify that the database is indeed good (will take a few hours to run)...
Users can do a full parse by rolling back their CP database to the first block and then starting up counterparty via the following commands (will take a few weeks to run):
fednode rollback 278270 counterparty
fednode vacuum counterparty
fednode start counterparty
fednode tail counterparty -
big shoutout to @pataegrillo for all his hard work on the parse/reparse updates... this was a very time-consuming and labor intensive process to track back ledger differences to the fork and apply protocol changes to fix things going forward.
-
thanks!!! 😄😄😄
-
Does Counterparty have design documents? Like, is there a database ER diagram? I’ve always wondered why the data is so denormalized…
Also, how are the next tasks to be worked on at protocol level decided? I want to vote on optimizing before adding new features.
A goal I would have is that the full parse is so optimized that the bootstrap can be completely removed. Make full nodes completely trustless by default. -
That won’t happen. The bootstrap prevents people from having to parse txs in for weeks…. Anyone CAN parse in the full blockchain data if they do choose, but the bootstrap will remain in place so that exchanges n ppl who want to run nodes can do so and spin up a node in hours instead of weeks… parsing is about as fast as it can go right now…. Your welcome to fork cp repo and work on parsing optimizations and submit a PR…. But the bootstrap will remain as the default action, as it has been since CP was first created
-
i think a goal of removing bootstrap simply because parsing is as fast as bitcoin core is noble but not sure how realistic it is
-
There is no “voting” on protocol changes or optimizations… this isn’t a democracy, it’s an open source software project…. Anyone can contribute code, but changes are not made via voting.
-
im sure its possible but would probly require a reimplementation of counterparty in some assembly language
-
In a perfect world we wouldn’t need a bootstrap, but considering it takes weeks to do a full parse, with most blocks taking under 1 second to parse, not sure we can optimize down to something reasonable….. speed vs convenience…. IMO as long as ppl have the option to full parse if they want, or do the faster reparse (hours of parsing not days), I think it’s fine….. ppl can now verify data in db or build db from scratch
-
No design doc I’ve seen…. Lots of devs have worked on cp codebase over the years so prolly explains why data is “denormalized”…. We welcome pull requests if you have any improvements you would like to make/review with the community devs here
-
I don’t think that is Counterparty’s responsibility to maintain a bootstrap. Is adding trust to a platform that its essence is being trustless
-
its verifiable
-
you can "trust" the bootstrap with a reparse on the DB which takes hours.... versus a full parse which takes days.... IF we are ever able to speed up CP to the point where it can sync within a few hours, yes, we can consider removing the bootstrap..... but saying there should be no bootstrap and people should have to spend weeks parsing is a non-starter.... exchanges and node operators dont want to have to spin up a node and parse for weeks before being able to interact with that node just so they can "trust" that they parsed all data... they would prefer a bootstrap and a quick reparse if they want to verify all the data in the bootstrap is valid/good.
-
-
-
Bitcoin is about “don’t trust, verify”. So, I believe the default in Counterparty should be trustless.
And if we study the risks of the bootstrap, it has already happened with v9.60 which was released without the full parse being verified.
Where in the repo is the process to create this said bootstrap? I find it very contradictory… -
lucky for you, you don’t need to use it
-
About the future plans, I also dislike how is seems like these are already decided. I’m taking about the Blackbox…
I’ve heard how people are against doing votes with XCP… but then an implicit vote is being done by people buying these tokens? What if what is promised in here is not done correctly? -
to clarify... yes 9.60.0 was released without a full parse, but YOU were the only one who forked off into their own ledger by running 9.59.... 9.60 database was fine, and now you can verify that information with a reparse or full parse.
-
there is a long history of “voting” in counterparty
-
id suggest digging through counterpartytalk
-
-
what are you calling a blackbox?
-
counterparty development attempts to mimic bitcoin development, hence the CIP process etc
-
Counterparty Newsletter – November 2022 | Counterparty
June sees some big steps forward in terms of Counterparty community strengthening- & lays groundwork to structure the XCP project for longevity.
-
you want to know who writes the newsletter?
-
At some point we had an official foundation and a general fund..... but, the foundation didn't do jack, and I was not comfortable holding the CP general funds..... BLACKBOXES were created as a way for people to fund myself as well as various CP things which do not fall under CIP development (the only other way devs can get funding in CP)..... the BLACKBOX approach is something I came up with so that people could donate directly to me in various buckets to keep CP Up/running..... bucket for server hosting API servers.... bucket for paying for exfhange listing maintenance (we need to pay monthly for volume generation bot), etc..... so you see, I would agree with you that BLACKBOX is not ideal... however, it has been working for the past 2 years to keep things moving along...... we sat for 2+ years with no foundation, no action, nothing really happening..... since that time CP has grown exponetially, the load on the servers is much higher, and the community is consistently asking for updates and improvements to the website, documentation, etc..... all that requires funding... no funding mechanism existted that was working before I created BLACKBOX items... I am not comfortable holding funds for the community (donated funds, controlled by foundation that does nothing)... I am ok holding funds that people donate directly to me to use on keeping CP up/alive/moving forward..... In a perfect world CP would have a decent dev budget to work from and we wouldn't have to use BLACKBOXes for fundraising.... unfortunately, it is where we are
-
we have Exchange listings only because of BLACKBOXES... we have xchain hosting because of BLACKBOXES... we have a CP general fund which has been used to pay Javier for the last year for all the misc bugfixes he has worked on which are not CIPs (again, the only official way devs can get funds from CP dev according to the official docs)
-
-
just sent Javier $750 yesterday from the BLACKBOX cp general fund to pay for the last month plus of work on the parse/reparse updates..... without BLACKBOXES, we would have no funds at all.... is BLACKBOX ideal? no..... but, it has been working for the last couple years to keep CP alive and funded, and will continue to work until the community grows and decides they would like another mechanism..... in a perfect world, a non-profit group would accept donations for CP, and a group of community elected individuals would have say over how the funds are spent... and the funds should be held in a multisig wallet.... but, unfortunately we tried that, the last 2 foundations were a shitshow..... one was destroyed by a conspiracy developer who threatened to sue devs for working on the project and the entire foundation decided it wasn't work the headache and quit........ the foundation that was elected a couple years later sat around and did nothing all year... no improvements, no fundraising, etc..... so, is BLACKBOX ideal, no... but, the other solutions to date have no worked.... open to changes in the future, but for now, BLACKBOXES work (and to be clear, they are entirely a peronal venture... yes, all funds are spent on CP, but they are to be used at my discression... as they have been for the last 2 years)
-
I dont call BLACKBOXES official... and I do my best to make it clear that the funds are being donated to me personally to put towards CP... but yes, some trust is involved... longer-term would like to remove that trust and get back to a group that works on moving CP forward, and who controls the funds. 👍
-
i'm not trying to start and argument but while it wasn't made public we did create a company and submit to the IRS to become a 501c(3) non-profit and they said NO
-
this was another option i explored earlier this year… https://magicgrants.org/funds/MAGIC Funds
Multidisciplinary Academic Grants in Cryptocurrencies
-
in the process I spoke with multiple large stakeholders and the general sentiment I got was that those who would give significant donations would prefer to fund individual developers directly
-
so i put it on the back burner
-
-
FYI... there is no repo for creating the bootstrap databases... we have a script which basically stops counterparty/counterparty-testnet creates a checksum file on the databases, and then creates a gziped tarball and puts it up at counterparty.io/bootstrap/
-
root@sites:/home/jdog# more /root/scripts/update-counterparty-bootstrap-files.sh
#!/bin/bash
#run as root
if [ "$EUID" -ne 0 ]
then echo "Please run as root"
exit
fi
CPSVR_DATA_DIR=/var/lib/docker/volumes/federatednode_counterparty-data/_data
# Time when script starts
date
# Remove any old bootstrap images
rm -f /tmp/counterparty-db.latest.tar.gz
rm -f /tmp/counterparty-db-testnet-7.latest.tar.gz
# Stop Counterparty so we can create bootstrap images
echo "Stopping Counterparty services..."
sudo -iu jdog fednode stop counterparty
sudo -iu jdog fednode stop counterparty-testnet
sleep 4
# Warn if we detect any write-ahead-logs (WAL) and SHM files
if ls ${CPSVR_DATA_DIR}/counterparty.db-* 1> /dev/null 2>&1; then
rm -f ${CPSVR_DATA_DIR}/counterparty.db-*
# echo "wal/shm file exists for mainnet counterparty-server!";
# exit;
fi
if ls ${CPSVR_DATA_DIR}/counterparty.testnet.db-* 1> /dev/null 2>&1; then
rm -f ${CPSVR_DATA_DIR}/counterparty.testnet.db-*
# echo "wal/shm file exists for testnet counterparty-server!";
# exit;
fi
echo "Creating tarball (mainnet)..."
cd ${CPSVR_DATA_DIR} && sha256sum counterparty.db > checksums.txt && tar -czvf /tmp/counterparty-db.latest.tar.gz counterparty.db checksums.txt && rm checksums.
txt
echo "Creating tarball (testnet)..."
cd ${CPSVR_DATA_DIR} && sha256sum counterparty.testnet.db > checksums.txt && tar -czvf /tmp/counterparty-db-testnet-7.latest.tar.gz counterparty.testnet.db chec
ksums.txt && rm checksums.txt
echo "Restarting Counterparty services..."
sudo -iu jdog fednode restart counterparty
sudo -iu jdog fednode restart counterparty-testnet
echo "Updating bootstrap images..."
mv -f /tmp/counterparty-db.latest.tar.gz /tmp/counterparty-db-testnet-7.latest.tar.gz /misc/
#/var/www/virtual/counterparty.io/bootstrap/
date -
the best part about magic grants are that they’ve already done all the legal paperwork
-
and this is important difference between a developer and a 'foundation' - also relates to @uanbtc point about Blackbox funding. The way I see it - the aspect that are not ideal about blackbox funding concept are the unfortunate reality we have been forced into by toeing the line of creating 'finacial software' we all want for the future but also not doing anything that could be considered illegal. 'Blackbox' in and of itself is essentially a play on the fact that the donating IS NOT promising anything, becuase if it was, it would be soliciating for a security...
-
-
We had/could get back Sasha on council for our formation as a compnay and applying to be a non-profit. The docs and info was just not actievly disributed since they dox my full name and home address
-
Bro... your in crypto long enough... time to get a PO box and start using that as your main address on anything except utility bills.... opsec... try to reduce your realworld footprint
-
jameson lopp did an aweome piece on this exact topic years ago... how to be crypto rich and still mostly off the radar... he put it out a year or so after he had all his drama with ppl swatting his house
-
tldr... create companies and have them hold everything, including your home
-
you dont need anyone knocking on your front door with a gun demanding your rare pepes
-
-
Unfortunetly probably not relevant as it relates to this, it seems any organization in the United States is unlikely to get tax-exempt status and thus would need to be organized more like a company then a charity. I mean this isn't uncommon, the bitcoin foundation doesn't exist anymore but we have blockstream...
-
-
-
we need to start up a Church of XCP.... religion seems to slide through pretty easy... Check out Church of Bacon... they've been a non-profit since 2010 🙂 https://unitedchurchofbacon.org/
-
had that joke in the bck of my head - but was trying to be more fomal LOL - That we'd be more likely to get tax-free if we just say we worship Satoshi 😂
-
"PartyChurch - Supporting all the parties".... could fund all "party" platforms... counterparty, dogeparty, liteparty, unoparty, monaparty, etc
-
-
I don’t think there is a bootstrap from the Bitcoin repo right? There might be from service providers though. I have no problem if there is an xchain bootstrap.
The counterparty-lib software is about reading/writing a Bitcoin subprotocol (speech? 😉). That is its purpose. The bootstrap is implying hierarchy and trust.
And to clarify, my main problem with Blackbox is that it seems like the future of the platform is already defined… isn’t this a decentralized protocol? -
How do you see things as already defined? Where do you see BLACKBOX collecting funds for something controversial? The protocol is decentralized, and improvements are made through the CIP process which has its own funding mechanism... so, where is the bad behavior happening with BLACKBOXES? Have you seen any misuse of funds or features being pushed on the community without going through the CIP review process? I get BLACKBOXES are not ideal.... but, not sure how your making the leap from ppl supporting BLACKBOXES to the future of the platform already being defined.
-
and again... Counterparty is not Bitcoin.... they share much of the same ethos, but CP and BTC are different beasts so consistently treating them the same is a disservice.... we've already clarified that IF parsing can be sped up enough that it can be completed in a few hours, then we can consider removing the bootstrap.... but, we will not be removing the bootstrap and forcing people to parse for weeks on end because "Counterparty should be like bitcoin".... Bitcoin syncs fully in 24 hours... CP does not, hence the need for a bootstrap
-
need my morning coffee n a run on the beach... still waking up... sorry if my words come across as grumpy... not meant to 🙂
-
-
there are checkpoints in bitcoin unless you run with assumevalid=0
-
Is not checkpoints, is about skipping part of the verification https://river.com/learn/terms/a/assume-valid/
And I think we all agree that if the parsing is optimized as much as possible, then the bootstrap could become unnecessary.
Does counterparty-lib has a configuration to not use the bootstrap? I just think it should be front and center if a node wants it or notAssume Valid | River GlossaryAssume Valid is a method for speeding up initial block download (IBD) by allowing a node to skip verification of each transaction and signature in older blocks.
-
in bitcoin, work, and the continued accumulation of work on top is a strong voucher of validity and the whole point is that it's easy to verify
-
currently the bootstrap dbs are downloaded if counterparty doesnt detect the counterparty.db or counterparty.testnet.db files exist.... for someone to do a full parse, they would need to rollback to the first block... I mentioned this yesterday including the commands to do so, since I'm sure you'll want to do a full parse.
-
fednode rollback 278270 counterparty
fednode vacuum counterparty
fednode start counterparty
fednode tail counterparty -
you should get tshirts made with this on it @uanbtc
-
i love the vacuum command
-
-
Thanks for letting me know the current alternative
But do you agree it would be cool to have the option as part of the conf file? -
might make sense as a fednode config file option... but just NOT downloading the bootstrap is not enough to get CP going... a sqlite database has to exist with the correct tables and such in order for CP to connect to the database and start parsing... so, would need code to either create a brand new empty database with all tables/indexes... or would need to download a "clean/empty" database bootstrap and start parsing blocks.
-
Feel free to submit a PR... happy to test it out and merge if general consensus here is that it is an improvement 🙂
-
I have used assumevalid=0 and done a full verification, modrn cpus can check a lot of signatures fast but I was just pointing out its not the default bitcoin core behaviour .. the default behaviour is to make things quicker/easier for the end user .. maybe the fednode script could be updated to have an option to skip the bootstrap download and go for a full database construction
fednode install full master nobootstrap -
I would make this tshirt 🐸
-
-
@pataegrillo ^^
-
i'll create a issue for this update and we'll get it in the next release... might push 9.60.1 out another week or so for testing... but, I think it is worth it.. no protocol changes in 9.60.1... just parse/reparse fixes, bitcoin version bump, database integrity check optimization to speed up CP starting up.... so no reason to rush the release out the door.
-
excellent, it's a good idea
-
assumevalid=0 would make a great tshirt ... get a pic of Adam Back wearing one and its a winner
-
Allow install with `nobootstrap` option · Issue #338 · CounterpartyXCP/federatednode
We should update fednode to a user to specify a nobootstrap option if they so desire. This will require updating fednode to allow specifying a CONFIG (base/full/counterblock), a BRANCH (master/deve...
- 30 November 2022 (26 messages)
-
-
-
Bump Bitcoin Core version to 24.0 by jdogresorg · Pull Request #337 · CounterpartyXCP/federatednode
Federated Node Build System. Contribute to CounterpartyXCP/federatednode development by creating an account on GitHub.
-
anyone here object (and have a valid reason) to upgrading to bitcoin 24.0? Been testing it running on a few of the servers and it runs fine and seems to be a drop-in replacement.... to me this is a minor update which just makes sense... but, dont want to be accused of doing things in the shadows (even tho everything is on github publicly).
-
Make a public poll
-
no, we are not taking every update to a vote... that is not how this works
-
if there is a VALID reason to not run Bitcoin 24.0, then we can hear the arguments here, or in the github pull request... as has been done in the past.
-
Counterparty vs Dogeparty · Issue #65 · CounterpartyXCP/cips
I would like to open a discussion about this. I'll start with my observations. It is my understanding that Dogeparty's main purpose is to be used as a "live testnet&quo...
-
FYI.. I closed this issue as the correct place to have this discussions is on a forum, where other counterparty community members can weigh in, and not just on github where only developers can see.
-
As the developer who spun up Dogeparty again, and who established the Dogeparty Foundation, and a former Counterparty Foundation member, I would be happy to answer any questions you have about the CP Foundation vs DP Foundation and the differences between them (hint, DP has warchest, CP doesnt).... once a forum thread is created on the counterpartytalk.org community forums, where discussions like this should take place.
-
I don’t mind it being closed (closing it is a message by itself). I’ll reply to anyone who writes here, as I believe GitHub has MUCH more reach than counterpartytalk
-
Juan... while I appreciate your enthusiasm... it is getting pretty frustrating you wanting to argue everything in github issues, and now using github to have "conversations" about a different platform "Dogeparty".... I also find it very telling that you would rather publicly create posts and stomp your feet and tell people that they should have discussions where you want instead of the offiicial forums that were setup for disscussions..... versus just asking questions here, or in the public channel, or on the forums. Seems to follow your general attitude since you got here... "I am Juan, I am here to save Counterparty, Here is how things should be done!" versus taking a milder approach of observing how things have been working historically, and figuring out how you can participate in a way that adds value without causing a bunch of drama and discord... versus screaming your head off at every change that is made you disagree with and pontificating to us how CP "should" be.
-
https://github.com/CounterpartyXCP/federatednode/pull/337
https://github.com/CounterpartyXCP/federatednode/issues/341
https://github.com/CounterpartyXCP/federatednode/issues/340
https://github.com/CounterpartyXCP/cips/issues/65Bump Bitcoin Core version to 24.0 by jdogresorg · Pull Request #337 · CounterpartyXCP/federatednodeFederated Node Build System. Contribute to CounterpartyXCP/federatednode development by creating an account on GitHub.
-
-
I prefer public conversations, in the correct places 🙂
-
counterpartytalk is public?
-
cuz i'm such a shady guy who says one thing in private chats and different things publicly? heh..... dunno why everything with you has to be so adversarial... it is unfortunate.
-
-
-
-
yes it is the same person that constantly disagrees
-
At least we can agree that it is personal for you.
-
-
-
-
old article, but still good overview of RBF. https://bitcoinmagazine.com/technical/the-case-for-replace-by-fee-and-the-case-against-1457383308The Case for Replace-By-Fee (And the Case Against)
The heated debate in the Bitcoin community throughout the past months not only concerns the block size dispute. Another technical change at the center of