- 01 December 2023 (25 messages)
-
Anyone here has a no bootstrap node ran from v9.60.2? -
Maybe in a couple weeks lol -
😆 I’m asking because my first attempt to update from v9.60.1 to v9.61.0, which triggered a reparse, the hashes are not matching (from early blocks) so I stopped.
But then trying again instead updating to v9.60.2, and the same thing!
Trying to figure out where the problem is. Thinking it can be the reparse itself…
I do no bootstrap. Don’t trust, verify.
It could be something wrong I’m doing, but man if is again a problem that is being hidden because of the bootstrap 😑 -
Oh joy. I’m hoping to have the time to try tomorrow.
-
Very joyful 🐸
-
I remember this episode… -
Last time I think it was because a tx used a non standard address and an interpreter was updated? Something like that.
-
The hashes are printed in the console in a confusing way, it prints the last characters instead of the first. I knew this once when deep into building, but forgot. So maybe the hashes were fine always…………. Just following up
-
Nice. Keep us posted
-
@uanbtc
-
Counterparty encountered a parsing issue with the new issuance IDs and doing a first issuance with description set to null...
Javier and I identified the issue immediately after 9.61.0 activation in block #819,301. The issue was identified in my testing of the new issuance formats on mainnet.
Counterparty API servers were down for a total of 31 minutes while Javier and I diagnosed/debugged the issue, got a fix in place, tested it, and deployed it to the API servers.
Additionally, I have also done a bunch of tests of the new issuance formats (asset/subasset ids 22/23) on mainnet... issue, reset, lock, transfer, etc.... all seem to be working as expected... so, putting out this hotfix release ASAP. -
The PR mentioned in this last attempt comment inactivated those changes.
https://github.com/CounterpartyXCP/cips/discussions/124#discussioncomment-7721979
The irony that the master’s v9.61.1 will be fixing issues caused by it. 🐸PROTOCOL MINOR UPDATE: V9.61 · CounterpartyXCP/cips · Discussion #124Let this be the space to discuss the next protocol-changing release, a consensus hashes affecting PROTOCOL MAJOR / MINOR UPDATE. Federated node operators, separate from the develop- branch leader, ...
-
FYI, accepting this PR is still an option. No need to rush a fix
-
is there any special upgrade process for nodes that weren't prior to the activation block?
-
This is a good idea, reparse on this, fix and when fix update -
Yeah, @reinamora_137 I don’t think so, but I would wait until the outcome of the current situation. I’m in the process of rebuilding addrindxrs and won’t go to the counterparty step
-
And my v9.60 node is intact, xcp.dev still running it smoothly
-
yeah we are still on 9.60 as well
-
i guess we are censoring the new transaction mess at least
-
Me too!
Consensus. Continuity.
🐸 -
WoW
-
I hope they accept your pr
-
Joined. -
"New official" 🙃
-
The one in consensus at least
- 02 December 2023 (3 messages)
-
My intention from day 1 has been transparent, Decentralizing CNTRPRTY (github.com/CNTRPRTY)
And I would have the relevant conversations in public, in the repo.
Hopefully, one day, it does become decentralized.
But first, it must finish with the hierarchies. At the top is Joe Looney. Everyone knows it. He manages the project, including the devs. Whatever he says, goes.
He stopped the contentious fork, after speaking with me. Using xcp.dev to confirm the fork was not necessary.
But then, he just throws me under the bus in the public forum.
You can stay in this chat, refute whatever I’m saying, defend yourself. Criticize me.
But this TRUTH will be a topic of discussion here. And this is me being considerate, as I’m saying this here and not in GitHub.Bitcoin and Counterparty ToolsDecentralizing CNTRPRTY: "Counterparty is Bitcoin. Is on top of Bitcoin. Is Web3. Is Web5. Two steps ahead." 🐸 - Bitcoin and Counterparty Tools
-
To whom it may concern:
As of now, only one small fix from v9.61 needs to be brought to v9.60 to continue running smoothly.
https://github.com/CNTRPRTY/counterparty-lib/commit/cb5408572bf66d05608cf1d39ca369dabc31872b- Fixed oracle function in util.py returning 2 values instead of 4 · CNTRPRTY/counterparty-lib@cb54085(cherry picked from commit cd3f87455670f56a2ed4e1fa81e53dc18c36c036)
- 06 December 2023 (42 messages)
-
Left.
-
Left.
-
Does anyone know if there is any of the create_ action/write api functions that does not fit in op-return? My understanding is that all of them do fit…
-
create issuance doesn't fit op return if description is long -
Yes that I know, and that is the elegance of it. Is transparent, abstracted
-
it defaults to multisig. with 2 outputs initially and then more outputs as needed . eg as stamps do and as do assets using arweave hoted jsons
-
create broadcast uses multisig for 55 chars or more
-
subassets with long names only need like 40 char descriptions to trigger multisig
-
Thinking about this because then the whole “enhanced file” proposal is just out of place. It does not belong in a protocol that tries to fit every action in the least amount of space (opreturn)
-
Mpma uses p2sh encoding by default so it’s funny that issuances with long descriptions don’t -
classic full https style ipfs links use multisig.. IPFS:hashes can fit in opreturn
-
mpma is the new kid on the block
-
True but it wasnt developed for mpma, it was for the evm
-
ahh i did not know that
-
cips/cip-0006.md at master · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
implemented by ruben, i love the title of the CIP
-
Im not an expert in Bitcoin transaction types, but it seems p2sh requires 2 transactions?
-
And if anyone can point me into the mpma documentation that would be appreciated, I’ve never used it
-
Is not part of the create_ functions, at least as seen in https://web.archive.org/web/20220103074128/https://counterparty.io/docs/api/#create_send
(Have to use archive because the new docs are a mess IMO)Counterparty API | CounterpartyDevelopers/API.md
-
Great idea with the archive of the docs. Do you have more links for docs? Or one link to rule them all?
-
-
destination (string, array[string]): The address to receive the asset.
asset (string, array[string]): The asset or subasset to send.
quantity (integer, array[integer]): The quantities of the asset to send. -
you use create_send and arrays for mpma
-
yeah it's a two transaction mechanism..and the 2nd can't be cpfpd and requires the first tx to be visible to the cp node creating the second tx ..its no good if mempool.space can see 1st tx but your avg 300mb fednode mempool can't .. so it becomes a high fee rate required
-
Not really, always going through the loop of going to archive.org first 😆
-
Ok so mpma is advanced usage. And I don’t know if it REQUIRES p2sh, or it could be done in multisig also…
-
I am using the docs on github ..they are most up to date
-
mpma p2sh doesn't create unspent utxos like multisig does .. in mpma the outputs in tx 1 are consumed in tx2
-
Got it! That makes sense
-
yeah but if you don't set high enough fees tx2 creation can fail until such time as tx1 is either mined or in mempool ... so it ends up creating tx1s that get abandoned
-
I got two identical tx1s learning this stuff the hard way .. they identical so only 1 of them can ever be consumed
-
Ok then the question becomes, can a send of only 2 recipients fit in op return? Is this still considered mpma?
-
I think a send with more than 1 recipient is mpma and mpma defaults to p2sh .
i not tried forcing a op_return with mpma ... the api might do it .. the question is as you say does it fit ? or will it get truncated? -
Another development, in my personal experience it seems like the updated addrsindrs takes much longer to sync than before… interested in learning the experience of others. @jp_janssen was the addrsindrs performance considered in this discussion? I know you were part of it…
-
Respect 🫡
-
You could use it with multisig but I don’t think the api as written will build that Tx for you, it currently forces use of p2sh
-
This is a great read. https://jpjanssen.com/how-to-reverse-engineer-counterparty-txs/
-
Would be awesome to have a playground style tool where you can create counterparty txs and it builds the hex string as you go with labels and things
-
Hehe that’s my goal with xcp.dev/wallet
Very basic for now but already working on some improvements for the next version -
Stop reading my mind. I’m trying to gather the data for encoding and decoding if you want to drop any resources.
- 07 December 2023 (22 messages)
-
I wrote some markdown files when building out my js library years ago, might help get started
-
xcp-tools-js/dex.md at master · loon3/xcp-tools-js
Javascript Library for Counterparty (counterparty.io) - loon3/xcp-tools-js
-
There are a handful of message types there
-
In my non-formal non-timed assessment, it seems like is not a ‘bit’. From what I remember it used to take around 24hrs, now I’m almost on 48 and is still not done (but close).
Your explanation makes sense, thank you for it.
I have been quite busy, looking at as much code as I can review, while giving priority to the PROCESS. Among other things…
So I do care.
The rust code I am not even close in familiarity compared to the python lib, so I talk when I know what I’m talking about. Still looking forward to learn about be rust side, as I believe this should just be all integrated into a single application if the coupling between the lib and addressindx is so tight.
As far as I know, only the lib effects were shown as “proof” that the change had no impact. Addressindx was not considered. Case in point why I believe they should be merged (other benefits can be starting to see consensus hashes from early on in the node sync process).
https://github.com/CounterpartyXCP/counterparty-lib/issues/1148
What is your username in github?Just 1st dispenser dispenses when batch-sending sats to multiple dispensers · Issue #1148 · CounterpartyXCP/counterparty-libThis is the transaction (generated with a simple blue wallet) https://blockstream.info/tx/11eb2b730e2e383a657c51d7b04bd55271d1e86ac9a2c74d3e3f6c78e88e23ff where correct exact sats were sent to 5 di...
-
Announcement!
xcp.dev has been updated! Mempool fixed (hopefully for good 😆), search added, and other minor improvements all around.
And still all open source. The only part is not yet open is the adjustments I made to counterparty-lib for the mempool “for good” fix, want to test those for more time before publicly committing to the approach taken. -
@hodlencoinfield is this yours? https://github.com/loon3/Tokenly-Pockets/blob/master/BVAM.mdTokenly-Pockets/BVAM.md at master · loon3/Tokenly-Pockets
Digital Token Wallet powered by Bitcoin. Contribute to loon3/Tokenly-Pockets development by creating an account on GitHub.
-
There is a link in there counterpartychain that is no good. Looks like the domain is dormant or wrong. Sending users on a chain of redirects and popups.
-
…But cool writeup and idea. Sorry if I’m wrong guessing who is who.
-
yep, but it hasnt been maintained for years
-
Lol was xcp.ninja working 8 years ago? Didn't know
-
yep it was my domain to do counterparty things and i let it expire lol
-
was funny to see it being used again
-
good domain imo
-
Yes jajaja
-
Neat idea
-
?
-
-
was basically a DIY ipfs
-
lol that's funny. Bought a month or two ago
-
it has great provenance 😁
-
BVAM is a great idea, I wonder why it didn’t catch on
https://github.com/CounterpartyXCP/cips/blob/master/cip-0007.mdcips/cip-0007.md at master · CounterpartyXCP/cipsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Acronym wasn’t catchy enough
- 08 December 2023 (12 messages)
-
Last good archive of this page. The real URL is 404. https://web.archive.org/web/20221002194116/https://counterparty.io/docs/enhanced_asset_info/DevTut: Enhanced Asset Info | Counterparty
Developers/Notes_and_Tutorials/enhanced_asset_info.md
-
Added to my reading list for sure.
-
-
-
Yes, i voiced concerns that multi dispensers might slowdown parsing. Jdog tested and concluded that 9.61 actually goes faster than before. Because addrsindex, if i understand correctly.
Also in the chat he mentioned that a full reparse based on addrsind should be possible and reduce a full parse from 2 weeks to 24h -
is Luke breaking the social contract ?
-
his opinions do make me laugh
-
i cant make my mind up which is funnier - the fact he spammed the blockchain with his mining pool posting bible verses or the fact he uses multiple op returns in his coinbase tx meaning he circumvents the 40 limit
-
Left.
-
The memes are writing themselves. What is Gentoo?
Gentoo in itself is a collection of free knowledge. Knowledge in this context can be defined as documentation and metadata concerned with concepts or domains relevant to operating systems and their components, as well as free software contributed by various developers to the Gentoo Project. -
Gentoo Social Contract – Gentoo Linux
News and information from Gentoo Linux
- 12 December 2023 (18 messages)
-
Who else has a v9.61.1 node here? Mine is not matching the hashes when comparing to xchain…
819300 was the activation block, and my last matching hashes is block 819576
😑 -
"block_index": 819577,
"block_hash": "0000000000000000000141b1d884d30239e12915f0fe76040bef264bb7361db2",
"block_time": 1701614108,
"previous_block_hash": "000000000000000000032c665ff59b06507e7024f80df5801ea5cd5cd0d7287e",
"difficulty": 67957790298897.88,
"ledger_hash": "f03dc08ef9f5098f0ddaa2881fed2bcf35e8b0a580891bf0f7fbdee60bc6564d",
"txlist_hash": "95fe71662419d7c27140c4dd2a6c6d2b23085221508ebd674bbc55ebbaa940ac",
"messages_hash": "a0568cece9bc3cae7bd1433cd8a4782bf931f0354874612c80e47245efbbc12c",
"block_index": 820000,
"block_hash": "00000000000000000000ba232574c32b4f0cd023e133c05125310625626d6571",
"block_time": 1701860856,
"previous_block_hash": "000000000000000000002660d26de87c900f770430d209814b238d15b17a0cfe",
"difficulty": 67957790298897.88,
"ledger_hash": "fa663ed80c1ac185162cb3d4101c9c5c0023e8b2ff3b4837b7378765b75bc472",
"txlist_hash": "e9ddc32575d88d3db4bab405e93375a36ac94c7c4e0f517a05042030a910bd24",
"messages_hash": "5a71fc010b4e24f457fade92b5da64de0c9383bbda694fab5036d9670aeac6d2", -
my node #2 matches those as well
-
been meaning to write a script to compare my two and against xchain one of these days
-
however i did use the bootstrap 🙁 been meaning to go back and start a full index on one of them
-
Mine is without bootstrap, and the reparse was triggered automatically… not sure how to proceed yet
-
I guess at least until everything matches, xcp.dev will stay in the last consensus version v9.60.
Seeing lots of ledger activity still, blocks with many messages while not seeing the same quantities in v9.61… but xchain does say is getting updated so let’s see… -
Welcome 🙏 -
nice to meet you ser
-
Very honored to have you both here! Welcome
-
Yes! Lately trying to decentralize it 😆. Not sure how familiar both are with the most recent developments. You should be able to read the old messages in this chat… but the main space is now https://github.com/CounterpartyXCP/cips/discussionsCounterpartyXCP/cips · Discussions
Explore the GitHub Discussions forum for CounterpartyXCP cips. Discuss code, ask questions & collaborate with the developer community.
- 14 December 2023 (19 messages)
-
@B0BSmith Are the 7800 sats per, from a large multisig still recoverable? Have you shared the source to run locally? I would like to reisue a XCP asset to remove the STAMP: description heading. I wish I had never put STAMP: in the description. I knew about JPJ and the history of Olga but at the time of issuance, I thought STAMP: was a requirement for the BASE64 to be rendered, not that it was joining a collection. Mine isn't a stamp per their protocol because I named my asset.
-
If you didn't use burn keys then those sats are recoverable
I didn't opensource the code.. I made it so anyone could use it, over Tor, and I couldn't know who was using it for what .. it only ever generated unsigned transactions, that user needed to sign themselves. -
it's currently offline as I broke it messing with adding a donation
-
It literally is needed to be rendered (on xchain anyways) -
a base64 string without stamp: prefix will not render on xchain unless you do something fancy like issue another "Issuances" afterwards with a pointer
-
You could have a regex instead that knows the common starts to the stamp strings (each file type seems to start their base64 with a certain set of characters, not suggesting you change what is established just a thought really -
Prolly uses that regex anyway to know how to render it
-
It was Cypher in the matrix who said I don't see the code anymore ... i render them in my mind ... ROIG0D IMG eyJw json .lol
-
Huehuehuehu
-
“You could” do a lot of things. I’m talking about “what is”. That’s what people see when they come to xchain or a stamp site. They see “what is”
-
I believe Xchain accepts named stamps. It follows CIP26: https://github.com/CounterpartyXCP/cips/blob/master/cip-0026.md
@mikeinspace has stricter conditions for Bitcoin Stamps, like need to be numeric asset, first issuance, not swept outputs (correct me if im wrong)cips/cip-0026.md at master · CounterpartyXCP/cipsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Correct, I was just referring to the “stamp:” prefix which is necessary even with Named Stamps
-
I need to get my fednode up. Is there a public explorer that shows an assets description? What about Olga?
-
Blonde, brunette, red head.
-
In the new indexer named stamps will be tracked
-
As cursed not Bitcoin stamps as they don't follow the requirements
-
But they will be tracked
-
Olga was a broadcast not an asset issuance
-
bitSTART renders base64 data url format (and stamp:)
https://bitst.art/DANKREKTbitSTARTDiscover Bitcoin Art [Counterparty / Ordinals / NFTs]
- 15 December 2023 (6 messages)
-
I wish the docs were better for counterparty. 😞
-
Yes...
-
For the past week or so counterwallet has been down because counterblock (counterwallets backend) has been choking on parsing blocks.
There is a problem introduced with the dispensers close delay. Everything works correctly in counterparty-lib except for the block_index in the message bindings. Instead of inserting the block_index of the actual closure, the block_index of the original tx that marked the dispenser to be close is used. This is generating a non-correlated block_index in the messages table, so now it cannot be assumed that greater the messsage_index equal or greater is the block_index.
Javier and I spent the past week looking into the counterblock parsing issue and trying out potential fixes to get counterblock parsing again without the need for an update to counterparty-lib. However, we have come to the conclusion that in order to get counterblock parsing again, the simplest solutions are to make updates to counterparty-lib.
Neither Javier or I feel this issue rises to the level required for us to do an immediate hotfix release without community/dev feedback (ie. not an emergency).
We have put together 3 PRs and present 2 potential solutions.
Solution #1
- Update counterparty-lib to correct block_index correlation (messages ledger will change)
https://github.com/CounterpartyXCP/counterparty-lib/pull/1293
Solution #2
- Update counterparty-lib get_blocks function to work with non-correlated block_index
https://github.com/CounterpartyXCP/counterparty-lib/pull/1292
- Update counterblock to handle the dispenser close delay.
https://github.com/CounterpartyXCP/counterblock/pull/196
It is up to the community and the core maintainers how they would like to address this issue.Correct `block_index` Used for Dispensers Closing Delay by pataegrillo · Pull Request #1293 · CounterpartyXCP/counterparty-libTHIS FIX IS FOR REFERENCE ONLY! This fixs the wrong block_index used when closing a dispenser with delay. With this fix there is no need to use the recent counterparty and counterblock PRs to fix t...
-
Thank you for this @c0rnh0li0
I’m glad things are moving into a more “transparent” direction… the intention seems to be there…
But using an informal chat for announcing this is not how I believe this should be done.
Just made this into a lib issue: https://github.com/CounterpartyXCP/counterparty-lib/issues/1294Issue with v9.61 in counterwallet+counterblock · Issue #1294 · CounterpartyXCP/counterparty-libFrom @jdogresorg in a chat: """ For the past week or so counterwallet has been down because counterblock (counterwallets backend) has been choking on parsing blocks. There is a probl...
-
Anyway… was going to announce that xcp.dev is finally in v9.61!
And v9.60 will be kept alive, at least until v9.61 hashes match (currently discussed in https://github.com/CounterpartyXCP/counterparty-lib/pull/1277)9.61.0 Release by jdogresorg · Pull Request #1277 · CounterpartyXCP/counterparty-lib9.61.0 Release Notes Bumped bitcoin core version to 25.1 (view) Adjusted DEFAULT_MULTISIG_DUST_SIZE (7800->1000) (view) Fixed issue with oracle function returning bad values (view) Fixed issue...
-
You can switch versions at the bottom of the page, which links to 960.xcp.dev
- 18 December 2023 (1 messages)
-
New CIP
- like stamps but 50% cheaper
- easy on nodes; file stored in p2wsh outputs but not in counterparty db
- test it out; links to tx builder for electrum and decoder
https://github.com/CounterpartyXCP/cips/discussions/126CIP33 – File Storage in P2WSH Outputs · CounterpartyXCP/cips · Discussion #126Use this tread to discuss CIP33 – File Storage in P2WSH Outputs.
- 19 December 2023 (1 messages)
- 21 December 2023 (3 messages)
-
admin
-
DONT ENTER THIS LINK
-
Got it. Sry
- 22 December 2023 (2 messages)
-
I’ve been meaning to research and share regarding arc20 and cbrc20. New ideas similar to what has already been done, riding the wave. These were mentioned by an anon in a stamps chat as something better.
-
Thoughts on arc20 and cbrc20 if any? I have no links at this time.
- 24 December 2023 (1 messages)
-
https://docs.atomicals.xyz/arc20-tokens
Thoughts? Not really, is just another satoshi tracking app like ordinals but with a different approach. And their c20-like tokens more integrated into the base protocol it seems - 26 December 2023 (3 messages)
-
Joined. -
Hello everyone. I'm a blockchain developer. Nowadays, I'm developing my project. But I have a risk. How can i send the bitcoin by using node.js.
Input: sender privatekey(taproot address), receiver address: taproot, send amount.
Could you help me? This is urgent work.
😔 - 28 December 2023 (13 messages)
-
Periwig @teysol can you share your GitHub usernames?
Is adamkrellenstein you @teysol?
Can’t find an Evan here: https://github.com/CounterpartyXCP/counterparty-lib/graphs/contributors
Asking to @ mention you in the repo, if is ok…Contributors to CounterpartyXCP/counterparty-libCounterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
Left.
-
To start I just want to thank you for such a beautiful platform you build. It blew my mind the fist time I discovered it around 2 years ago, after playing with writing data in the limited op_return, never imagined it was possible to build a complete universe with such a small amount of data
But then also having the multisig for higher data needs, so elegant!
And proving full SQL on the timechain can work 🤯
(Sorry for the suckup lol but you really deserve it! My understanding is that even Ethereum came out of what was proven possible with Counterparty. Yet, you keep low key… maybe by choice so I’m not sure how much you want to be involved again…) -
Credit where credit is due. Jeremy has kept infrastructure running for many years. And users like Joe and most recently Mike have build the memes that fuel it all!
But a refocus on the core technology is due imo.
How involved you want to get again? I would really like to know your input on some recent developments, and next ones… -
Got it! Thanks for being around
-
Left.
-
super cool to have a legend back in action! Anything stirring up your interest in what people are requesting so far?
-
Would love to get your thoughts on whether psbts of asset sends could enable btc trading using a similar model to openordex.org
-
I think it should work with a traditional asset send that uses the dust output as recipient address
-
Could open up a lot of possibilities without any changes to the protocol
- 29 December 2023 (8 messages)
-
One very basic one missing is having the unpack available for all message types. The api only provides this for send
https://github.com/CounterpartyXCP/counterparty-lib/blob/e65172a6700a6a45207120ca082da2673d8b240c/counterpartylib/lib/api.py#L888counterparty-lib/counterpartylib/lib/api.py at e65172a6700a6a45207120ca082da2673d8b240c · CounterpartyXCP/counterparty-libCounterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
It will help organize the code also. Very much needed for some critical ones like issuances
Would like to know your input on issuances and the changes done in the last couple of releases… -
Let me be more specific. First would like to learn what was the use case / purpose of callability?
-
Here’s a basic overview of how it works with ordinals… https://twitter.com/mononautical/status/1735686744534585411
- 30 December 2023 (3 messages)
-
For the past week or so counterwallet has been down because counterblock (counterwallets backend) has been choking on parsing blocks.
There is a problem introduced with the dispensers close delay. Everything works correctly in counterparty-lib except for the block_index in the message bindings. Instead of inserting the block_index of the actual closure, the block_index of the original tx that marked the dispenser to be close is used. This is generating a non-correlated block_index in the messages table, so now it cannot be assumed that greater the messsage_index equal or greater is the block_index.
Javier and I spent the past week looking into the counterblock parsing issue and trying out potential fixes to get counterblock parsing again without the need for an update to counterparty-lib. However, we have come to the conclusion that in order to get counterblock parsing again, the simplest solutions are to make updates to counterparty-lib.
Neither Javier or I feel this issue rises to the level required for us to do an immediate hotfix release without community/dev feedback (ie. not an emergency).
We have put together 3 PRs and present 2 potential solutions.
Solution #1
- Update counterparty-lib to correct block_index correlation (messages ledger will change)
https://github.com/CounterpartyXCP/counterparty-lib/pull/1293
Solution #2
- Update counterparty-lib get_blocks function to work with non-correlated block_index
https://github.com/CounterpartyXCP/counterparty-lib/pull/1292
- Update counterblock to handle the dispenser close delay.
https://github.com/CounterpartyXCP/counterblock/pull/196
It is up to the community and the core maintainers how they would like to address this issue.Correct `block_index` Used for Dispensers Closing Delay by pataegrillo · Pull Request #1293 · CounterpartyXCP/counterparty-libTHIS FIX IS FOR REFERENCE ONLY! This fixs the wrong block_index used when closing a dispenser with delay. With this fix there is no need to use the recent counterparty and counterblock PRs to fix t...
-
Message forwarded from the "Official Counterparty Chat"
-
Is already in GitHub: https://github.com/CounterpartyXCP/counterparty-lib/issues/1294Issue with v9.61 in counterwallet+counterblock · Issue #1294 · CounterpartyXCP/counterparty-lib
From @jdogresorg in a chat: """ For the past week or so counterwallet has been down because counterblock (counterwallets backend) has been choking on parsing blocks. There is a probl...
- 31 December 2023 (1 messages)
-
Thanks for taking the effort. I will post a comment after the holday.
Happy new year everyone!
XCP Dev Chat
Public archive of Telegram messages.
