Hi Guys, Let me introduce a technical improvement by my limited company.
my company "Monami-ya LLC, Japan" succeeded to swap "a Counterparty asset" and "BTC on LightningNetwork" with no trust.
We use a trick similar to the submarine swap method.
The press release is here: https://www.value-press.com/pressrelease/301214 (in Japanese)
Operation logs are here: https://gist.github.com/monaka/799af5022704cf3f0157bc048ad3443f (in pidgin English)
We'll improve our code and release products soooooon.
You might buy PepeArts by your Lightning wallets in the near future. :-)
- 01 August 2022 (3 messages)
-
-
Joined.
-
@monamona_monaka interesting ^^
- 03 August 2022 (5 messages)
-
Have him do a transaction from the address like a btc or asset send…. After that the pubkey will be known n you shouldn’t get the error again…. It’s only an issue for brand new addresses with no outbound transactions yet - 06 August 2022 (2 messages)
-
Hello, is it possible to obtain the encoding of a transaction as part of a counterparty api/cli response? Like it is possible to specify as an advanced create_ request parameter, but now I’m interested in having this encoding included in the response -
Or being able to query/filter based on the encoding
- 07 August 2022 (6 messages)
-
You can specify the desired encoding on an api request and get that type of tx returned
-
Technical Specification | Counterparty
Read API Function Reference
-
Check out the “encoding” param
-
Yes that is how to create a transaction with a specified encoding.
But what I am interested is in reading data, make a query that returns transactions with their encoding. Or if the query can filter for a specified encoding, that also works -
You’d probly have to filter through all the txs yourself as I don’t believe encoding type is recorded by the block parser -
Ok thanks, I will need to learn how to do that. I’ll look at the source code
- 08 August 2022 (1 messages)
-
Left.
- 09 August 2022 (9 messages)
-
Left.
-
is xchain acting odd for anyone else -
seems that a dispenser that should have been confirmed is not showing up
-
counterparty does a database integrity check on startup which at times can take a LONG time to finish.... as in, a couple hours or more... so, whenever I update the CP servers, I update host1.xchain.io and get it up and current, then focus on updating the other servers, since they could be down for a few hours
-
that integrity check issue should go away in the release after next
-
stop forcing database integrity check on startup · Issue #1192 · CounterpartyXCP/counterparty-lib
Currently we do a database integrity check when counterparty starts up, and at times this integrity check can take a very long time to complete if it has been a while since CP has restarted. The en...
-
thanks guys for the quick response.
- 10 August 2022 (1 messages)
-
Joined. - 11 August 2022 (31 messages)
-
Great resource. Is there a swagger list for counterparty nodes server api? I’m traveling and only have mobile access for a while. If you haven’t developed with swagger check out, https://generator.swagger.io
-
No swagger list that I’m aware of yet
-
what format is the data returned in the "tag" field for destructions via xchain api, I think that it is the memo data? If it is what encoding is it
-
-
Yes, it is a memo
-
thanks
-
sorry off topic, trying to figure out why this json would not show on xchain, I think that it is valid but have not tried to host a json before
-
-
the JSON is valid.... looking into why xchain isn't displaying it... I relay all JSON requests through xchain.io... and for some reason the relay is not returning your json
-
hmm I was trying to debug the js and saw the reply but it was always null
-
perhaps no return the correct mime type
-
I just posted the file direct
-
I see the relay script get the JSON, then pass it to json_decode() which returns a "Syntax error"
-
but if I look at the JSON and copy/paste it into jsonlint.com... it validates as fine
-
so, i'm kinda stumped what the syntax error is...
-
maybe just upate the json to remove all fields and add the fields back one by one until you find out which one is causing the issue
-
you can test if it works through the relay here https://host1.xchain.io/relay?url=https://robotlovecoffee.wtf/json/skife/RUGGEDROTHKO.json
-
I think it is how it is being served as when I put other json that works it still fails
-
but I should be able to just post up a file to a server right?
-
yes
-
/*********************************************************************
* relay.php
*
* Handles relaying requests for JSON and PNG files.
* - All content can be delivered via https/ssl (doesn't break browser SSL lock)
* - Most .json files do not pass Access-Control-Allow-Origin header (xhr refuses to make request)
*********************************************************************/ -
now I remember why I relay JSON through the relay on xchain 😛
-
so I need to enabke CORS>
-
so odd still does not work
-
this is different then the json pulled for the Green Bar corrrect?
-
like the basic flow
-
as that is on the same infra (Azure)
-
-
using postman this should be good, not sure what else to try
-
content in json is from another card
- 12 August 2022 (43 messages)
-
Asterisk may not be your friend? Try explicit?
-
ok I have put a file on a wp site, a fleek, site and the azue all fail with null
-
correct... that json is from the project, not individual tokens
-
the relay scripts makes a curl request directly for the JSON... so the access-control-allow-origin header doesn't really come into play unless trying to make an XHR request from the browser.
-
Gimme a sec... i'll try to tweak xchain to have the browser try and request the json directly first... and if that fails, THEN try to use the relay.. should perhaps fix the issue
-
ok cool
-
I have a file down to just basics here
-
-
Did you try smashing F5 repeatedly?
-
perhaps my file is the problem, seems like this would be an issue all over the place. This is direct from IPFS
-
-
I was able to get a file to work on fleek that was a response from postman for a card that worked, trying to see if I can update with other data, I hope that this is not just a HUGE waste of time for you guys.
-
-
it looks like requesting the JSON directly from the browser first, then failing over to requesting through the relay is working fine now.... update your json as you wish 🙂
-
I thought I fixed it 🙂
-
and was making you guys run circles
-
I basically saved a valid response from postman
-
and then posted that to fleek (ipfs) and it worked so took that file and moved it to the other places and it started working
-
so was this just bad data (file) on my end?
-
your json was fine... just something funky in the way PHP was decoding it and failing in json_decode() when using the relay..... now that xchain tries to have the users browser request the JSON file directly from you, seems to be working fine.
-
well thanks as always for helping
-
-
I do work in windows, via vmware fusion with visual studio
-
was thinking it was an encoding issue of some type perhaps but could not figure it out
-
I'm very excited to have CIP3 fully funded 👍
One principal concern though; if used assets (where all tokens are returned to issuer) can be reset, then divisibility become a mutable property. Light wallets will need to trust an api. Today they can keep a local table of divisibility statuses.
The solution is simple. Don't allow divisibility reset if a transfer has ever been made.
https://github.com/CounterpartyXCP/cips/issues/53Allow reset of used tokens? · Issue #53 · CounterpartyXCP/cipsShould assets with previous token transfers be allowed to reset divisibility? The implementation on Dogeparty does allow this: In theory any asset can be reset if all tokens are returned to the iss...
-
Found an api request to a specific block that is failing. Not including this block works, but if this block is included in any range, it fails.
{
"jsonrpc": "2.0",
"id": 0,
"method": "get_destructions",
"params": {
"filters": [],
"order_by": "tx_index",
"order_dir": "ASC",
"start_block": 747248,
"end_block": 747248
}
} -
Returns:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.</p> -
I created a github issue and we are looking into the problem now... https://github.com/CounterpartyXCP/counterparty-lib/issues/1195 ..... The only issuance that took place in that block was https://xchain.io/tx/bf05e673216b6511580ad70ffaf49cdcb1b49b0c73b41087daf024b0c8b7993e .... and a quick look at that issuance shows it has some funky characters in the tag.... most likely that is the cause of the API failing... but will dig into it more with Javier and get it resolvederror when trying `get_destructions` API request · Issue #1195 · CounterpartyXCP/counterparty-lib
when requesting get_destructions with a start block of 747248 an error is thrown. Request { "method": "get_destructions", "params": { "...
-
Thank you for raising your concerns. 👍I think this would be a VERY limited case where ppl have tokens that are distributed to different addresses and then they return all the supply to the issuing address... I fail to understand why allowing them to reset token supply is a big issue..... to determine if supply is divisible/non-divisible, you can simply lookup the last issuance before the tx in question.... that will tell you if the asset was divisible or non-divisible at the time.... there is a display issue on xchain where destroyed token supply shows up as wrong when using CIP03 (on dogeparty), but that is a simple update to xchain to display the correct destroyed amount based on the previous divisible/non-divisible state before the destruction.
-
perhaps you can articulate why this is such a concern for you.... all the CP wallets already rely on using the API to get transaction info (all wallets either get from counterblock/counterparty-api in counterwallet or xchain API in freewallet.io).... I am not aware of any wallets which parse in CP transactions directly and decode the data directly from bitcoin transactions... so there is already the dependency to rely on CP/xchain APIs to get CP asset info
-
Might be more of an issue for people caching data -
And would then force people to hammer the api a little more
-
I was going to create the issue and saw you did it already. Thanks!
-
Even though I’m still learning about Counterparty, I am clear in what makes Bitcoin special. So, I have concerns with CIP3. Made this issue about it following up on yours @jp_janssen
https://github.com/CounterpartyXCP/cips/issues/54CIP3 concern: immutability in Bitcoin · Issue #54 · CounterpartyXCP/cipsI have concerns with CIP3, but I'm fairly new to Counterparty, so let me know if there is any misunderstanding in the following (and in the second part there are actual questions). Followin...
-
In the future please put your comments in the relevant issue, no need to create multiple issues for the same thing
-
Is not a comment about the specific issue brought up by JP. I just mention it. It is a completely separate issue about the CIP overall
-
heh... did you review the CIP before posting your feedback?
-
cuz... the CIP has been open for 8 years... has overwelming community support... and you asked about where is the discussion, yet had you viewed the CIP, you would have seen the link to the discussion at https://counterpartytalk.org/t/cip-reset-token-divisibility-statuses-for-unused-asset/1643CIP03 - Reset Token & Divisibility Statuses for Unused Asset
It would be great to hear what you think before formalizing a CIP. If the asset owner holds the entire supply and the asset is not locked, then allow the owner to reset the supply (e.g. set the supply at zero) and change the divisibility status. This can be achieved with a function reset(asset, issuance, divisibility). Asset must be the name of an asset owned by address making the call. Issuance is the new total number of issued tokens. Divisibility is boolean; true if divisible, false if indi...
-
i'll do my best to answer your questions in the issue
-
tried to address your concerns in the response
-
I did read the CIP before posting. I did not check that link, I missed it. But now that I check it I see the last comment was in February 2019, and this seems to be ready for release so maybe a new discussion “closer” (as in GitHub) is warranted. I was following up on another related issue which was also done in GitHub.
Thanks for taking the time to respond. Will look at it now… -
Read it, thank you. I think I will respond, but need to process it first. I’m ready to leave my desk for today 😆
-
Sounds good.. and yes, we definitely are open to having disscussions on concerns... I look forward to your reply 🙂
- 13 August 2022 (14 messages)
-
My concern is mostly a principal one but also relevant for future wallet designs.
Practically speaking every wallet relies on API for divisibility so it won't change anything for current wallet implementations.
In theory a dishonest API can provide wrong divisibility and mess up enhanced send but not cause loss of fund (except in very rare cases). But for DEX orders real loss can occur.
Best practice for light wallets should be a local table of divisibility statuses. CIP3 (without my suggestion) breaks this.
I don't see much downside with this suggestion as it will only affect issuer who already distributed tokens and need them back. Zero or very few such cases.
With my suggestion every asset will have either state;
0 - no transfer made, divisibility may change, api needed, mutable state
1 - transfer has been made, divisible, no api needed, immutable state
2 - transfer has been made, indivisible, no api needed, immutable state -
💰 XCP Cobweb DeDuster 💰
Check your counterparty addresses to see if you have a hidden yet redeemable unspent multisig dust balance!
http://lopbicp5dgkifkpx2x3nnl76sn724swgkh5cevg3at7u4osibwbdtaad.onion
Multisig dust is created when issuing XCP assets with long descriptions or when making broadcasts with long memos.
If you make these types of transactions often the dust can soon build up.
This tool creates an unsigned pay-to-self redeem transaction and generates the bitcoin-cli command used to sign the transaction with your private key.
Don't delay reclaim your satoshis today!
💰 🤑 💰 🤑 💰 -
Thank you for raising your concern JP.
What about cases where the asset owner registered the token and issued 1.00000000 tokens, then later swept asset balances and asset ownership to a new addresses (I have actually done this with a few thousand assets). With your proposed fix, the asset owner would be out of luck simply for moving the asset supply and asset ownership to a new address and would not be able to reset the token/supply because the balances table would show more than 1 record -
-
Nice work Bob ! If you tweet out about this, let me know and i'll retweet from the CP account and my personal account
-
the thing is there is no such thing as a light wallet, you ALWAYS need to query a node for balances because a light wallet can’t determine tx validity
-
if you’re querying balance then you need to query divisibility as well especially if you’re sent an asset that you didnt previously hold
-
i would certainly support including divisibilty as a parameter returned with the get_balances call
-
that would make life much easier for me personally
-
create a github issue for it and we can add it to this next release 🙂
-
-
Issues · CounterpartyXCP/counterparty-lib
Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
added
-
Thanks but I deleted my personal twitter account a few years ago
- 14 August 2022 (8 messages)
-
I thought it would affect none or very few assets. So now knowing there are thousands, i agree the best overall tradeoff is to go with the dogeparty implementation.
-
Query balances is one thing, but signing a tx and potentially lose funds if API is dishonest is something else. This unfortunately is the case with some xcp transactions. Can be eliminated if divisibility is added as a parameter in txs.
-
Not sure I follow, if the api is dishonest divisibility is the least of you concerns. In regard to divisibility, you could just assume non divisible for all cases and worst that happens is you send 1/100,000,000 of what you meant to send
-
For enhanced send yes. In theory, in the other direction may send 100M x the amount but will realistically fail since you dont have that much.
For dex order, isn't the risk you will sell at a 100M x lower price? -
is this a criticism of the current state of counterparty or of CIP3?
-
you have to either run your own fednode or trust the one you’re querying, its impossible to know the validity of a tx without a node
-
No criticism. Im the original author of cip3. Just thought a slightly better implementation were possible. But after realizing it would negatively affect thousands of assets, I withdraw my suggestion. Im all for implementing cip3 exactly as on Dogeparty.
- 15 August 2022 (16 messages)
-
I understand I might be in the minority here, specifically because I am newer. But this is also a new perspective, viewing CP as it stands RIGHT NOW with all its current functionality. I really believe CIP3, in its current form, is not the best move. I try my best to explain myself here, and would really appreciate feedback from anyone
-
Is the cip3 implementation an issuance message type?
-
I just read the GitHub comments on it and will respond to Juan’s comments later today
-
It seems to me Juan is afraid that changing divisibility isn’t restrictive enough, is that accurate @uanbtc ?
-
I dont think it is a new message type... just a serialization format change from >QQ??If to >QQ???If to make room for the reset flag
-
CIP3 breaks the fundamental way of calculating the total quantity of an asset. Why allow a change where people can get with misusing the platform, without any cost, while costing the fundamental ARCHITECTURE of the platform, forever?
I believe, this CIP is only being considered from the point of view of people that have asset names they want to UNDO divisibility (as asset quantity changes can already be done with issuances and destructions) to resell them. If the rationale is they have 100% of the issuance, then, why not allow undo-ing locks in the same situation? It just feels like an unhealthy feature addition, as it incentivizes and rewards NOT using assets.
If something like CIP3 wants to be done, it needs to be done in a way that adds general value for everyone in the community, especially the new people which if Counterparty grows as we all wish, WILL become the vast majority. As it stands right now, for a niche and temporary use case, CIP3 is affecting the fundamental, Bitcoin-space-respecting, ELEGANTLY SIMPLE asset quantity calculation: asset_quantity = sum_issuances - sum_destructions -
As someone who has issued an asset as divisible by accident I think a meaningful fix to prevent it in the future is to make the selection of divisible/nondivisible be an unselected radio button that is required (in FreeWallet). The main issue with the interface is that the divisiblitly is of upmost importance and yet the interface down plays its importance by almost visually hiding it to the right and preselecting a choice. -
This -
yea, I can do that in the next release
-
Yes, it's completely a UI issue. That's why so many people screw it up. It's very easy to miss. And most people don't want to create a divisible asset. Defaulting it the other way still leaves open the possibilty of mistakes but will likely be far fewer.
-
But is interesting that divisibility (which is just an interpretation) cannot be considered as it is in its raw data type, a big integer. Could it be possible to treat all non-locked assets at the satoshi level, and then with locking is that divisibility must be chosen?
- 16 August 2022 (61 messages)
-
At the protocol level all assets are treated as satoshis. For example, there are 300 divisible FDCARD, but the database says the supply is 30,000,000,000. There are 100 indivisible JPJA, thus the DB says 100.
With cip3 i expect changing a divisble asset with supply 1 to indivisible will give supply 100,000,000. Ie the techincal supply stays the same while the displayed supply changes. (Correct?)
Divisibility is just a parameter that tells wallets how to display balances. My concern was about a theoretical improvement for light wallets which has never been a topic anyway.
The intention of cip3 is to make thousands of the best names usable again. I think this is a great benefit to our scarce namespace. At a small technical cost. -
I would have thought a divisible asset with supply of 1 when made indivisible would have a supply of 1 not 100,000,000
but from reading the github issues it seems supply gets reset while changing divisibility ? -
This sounds very logical. From a developer new to XCP; I believe the community and project could benefit with some small changes to the grammar used in the project. Maybe freewallet and similar should be called a client, not a wallet. The server software has the same name as the protocol (close) I have a note with more thoughts on this topic and will extrapolate later, but I wanted to share that thought while a bit relevant. Thoughts?
-
I agree. There is too much coupling between Counterparty as a protocol and an application backend. Freewallet has taken the role of Counterparty client. And the same has happened with with xchain, which is also private software, but Counterparty should not be xchain’s backend.
I AM GRATEFUL for these solutions, but Counterparty has so much potential, the core protocol needs to delegate application features to the community. Get simpler, leaner, and focused. Then the rest of the community builds the applications -
Unfortunately there is a large gap between “the community should do X” and that actually happening. I would love for there to be more wallets, block explorers, etc….. unfortunately ppl haven’t stepped up to write those, so I was left with the decision to write things myself, or wait around for what “should be”…… I prefer to have something that “just works” now while continuing to wait for others to step up n buidl😀👍🏻
Always room for improvement, but I don’t see any of CPs core features as something that should be pushed up to the application layer (we tried that with my coinvend service and tokenly’s swapbot services…. Application level vending machines)…. Ppl clearly didn’t like the functionality in the apps (even tho very similar to what we have now) and preferred the functionality being in the base protocol… as evidenced by very little coinvend/swapbot usage over years, and the explosion of dispenser use in the past 1.5 years.
Just my 2 sats worth😀👍🏻 -
I understand. But I believe that will start to change. After the NFT boom, a lot more people are discovering Counterparty
-
My point is: is not a small technical cost. Can anyone point me at the alternative implementation of total asset quantity?
-
as noted in the response to your CIP issue, the formula for calculating total supply/quantity has not changed.
-
total_quantity = sum_issuances - sum_destructions still works to determine the total quantity even after CIP03, since before an asset can be reset its existing supply will be destroyed via destructions.
-
get_supply() in the API gets its supply info from until.asset_supply() which you can see is doing exactly that.. subtracting destructions from issuances to get total quantity/supply .... https://github.com/CounterpartyXCP/counterparty-lib/blob/master/counterpartylib/lib/util.py#L694-L700counterparty-lib/util.py at master · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
What is missing from the documentation? We have API docs that tell you how to make requests to Counterparty, what you get back, and how to sign the transaction and broadcast it. What do you suggest we add?
-
I agree with you that we definitely need more documentation, but I am curious what documentation you would like to see beyond what we already have available?
-
Hello fello devs! I have been building a leaderboard for Bitcoin Coaster cards using the xchain API. I am hitting the API and saving data locally to my database.
I've hit a limit for the balance query. It appears that when I do an API call for balance the response is limited to the first 500 cards held alphabetically per user.
Anyone have a suggestion for getting around the limit? Is there a more specific call I can make. I only care about some specific assets. -
Hmmm, I am using PHP and curl to to request data by hitting a URL like
https://xchain.io/api/balances/addresshere -
-
Oh, is there a different API?
-
Ok, so if someone knows how to make a more specific API call to xchain please share. If the response is limited there must be a way to do a more specific call.
-
The asset_supply function will stop working as is, because the quantity of the issuances/destructions will have different interpretations, so their SUM(quantity) will break. I’m interested in learning the NEW version of these queries. What I am saying will become extremely evident, CIP3 breaks fundamental assumptions of the protocol!
-
Ok, I think what I need to do is query each /address/ first to find out total number of assets. Then if an address has more than 500 assets I will have to do mulitple paged calls for each 500.
So at minimum I'll have to do 2 calls for each address. If someone knows how to get the info in fewer calls please share. -
read the API docs closer so you can paginate through all the results 😛
-
Paging
The XChain API supports paging and allows users to customize how many records are returned via {page} and {limit} parameters.
Method Endpoint
GET endpoint/{page}/{limit} -
soooo.... /api/balances/address/1 = page1 1-500..... /api/balances/address/2 = page2 501-1000, etc
-
xchain API was created so all the data in CP could be easily accessed via a URL without the need for a POST and a bunch of params... /api/asset/ASSET ... /api/balances/ADDRESS ... /api/dispensers/ASSET, etc
-
xchain limits to 500 balances on /api/balances endpoint... but, you can page through the results to get all your balances... I just limit to 500 balances per request, but you can request all the balances with additional API requests 🙂
-
Thank you for the info! I admit that I did miss some important part of the docs there. I am sorry for that.
-
And I do find it easy to work with. So I like it
-
Not sure what your talking about with your "different interpretations"..... the sum of issuances - destructions will add up to current supply, that is not changing.... Before an asset can be 'reset' any existing supply is destroyed (read that again, any existing supply is destroyed before new supply is issued)... so that means your calculation total_quantity = sum_issuances - sum_destructions will equal 0 BEFORE any additional supply is issued, and when additional supply is issued, the supply is still calculated the same..... If your going to make wild accusations about CIP3, then please back them up...... sure seems like the reset flag has been operational on dogeparty for 3+ months and everything is working fine with no issues or user complaints. 🤷🤷🤷 Sorry if I sound overly defensive, it is not my intention :)
-
You just need to look at the response and the API docs a bit closer 🙂
-
-
I pass a "total" field in the top level of the JSON which tells you how many results you have
-
so you can simply make 1 request to get the first 500 assets.... then check if "total" is greater than 500... if yes, request page 2... repeat for page 3, etc
-
Oh that is very good. You are making me look like I can't read which seems like it. Hahaha Thank you
-
my bad.... LOL... I am just replying to the messages in order... hadn't seen you had already replied to me 😛
-
muh bad... too many chats mang 😛
-
-
No, this is good info! I really appreciate it. Thank you
-
I was trying to make the API as easy to use as possible... cuz when I was writing it, I knew the end goal was to write freewallet 🙂
-
I got out of sorts because for the vast majority of addresses I didn't hit any limit so as I was coding it up I missed the edge cases. I should have studied the API docs better before asking. Glad I got the help though!
- 17 August 2022 (44 messages)
-
Your not alone in your mistake... I did the same thing in the first few versions of freewallet... had to have some holders with over 500 tokens tell me my wallet wasn't showing all their balances. 😛
-
I tend to host most of the CP/DP nodes on ovh.com .... they have unlimited bandwidth, built in DDOS protection, and decent servers with 64GB RAM and 8-12 Cores.... if you need any help setting up a node, feel free to ask... pretty straightforward tho 🙂
-
Don’t worry about tone, I’m also trying to defend my point.
The interpretation I am taking about is: when an asset is divisible, it’s quantity means satoshis. When it is not divisible, it means the full integer.
Those queries are not including any kind of filter for when divisibility changes.
If currently there are few places in the code where asset_supply is called, then it might be possible to not encounter the bug yet. How many assets have changed divisibility in dogeparty? Have they tried to change divisibility multiple times, with issuances in between? Isn’t it obvious that the quantities will not add up because of how divisibility interprets quantities?
I think is better to talk about these in the GitHub issue as liking to code makes more sense there… -
Sounds good... if you find any cases in the code where you feel that the quantity is being calculated incorrectly, please feel free to point them out on github and we will most certainly address them if there is indeed an issue 🙂
-
You say "The interpretation I am taking about is: when an asset is divisible, it’s quantity means satoshis. When it is not divisible, it means the full integer.".... but I believe that your going with the incorrect assumption that you should be able to parse in all the issuances/destructions from blocks and then determine quantity that way, which even BEFORE CIP03 was not the case. Only Counterparty software can determine if an action is valid or invalid, so just parsing in a destruction or issuance message from the blockchain is not enough to determine if that transaction is seen as valid or not. Its not like we are breaking something that was working before (you could NEVER parse in issuances and destructions from block alone and determine supply)
-
so, no matter what, your going to have to "phone home" to the CP API to determine if a transaction is valid.
-
Anyway, if you find any issues in the code, please point them out and we will review them and address any issues 🙂
-
??? No “don’t trust, verify” in CP? How can you say the info in the blocks cannot be relied on?
-
because the transaction in the block just says "This user says to transfer XCP from addressA to addressB"..... with no regard to if addressA actually has the XCP available in its balances to send.... Only AFTER counterparty parses the transaction and verifies that the user has the XCP in their addressA, THEN the XCP is debited from AddressA and credited to addressB..... so, you see, all Bitcoin does is hold requests for CP "move this, issue this, place this order".... Counterparty is what parses the transactions and determines their validity
-
you can't just see an issuance transaction and assume it is valid, many fail
-
I get that. But issuances and destructions should be a 100% reliable and simple way to obtain total asset issuance. Messages on blocks are the source of truth.
I hope that just because dogeparty decided to complicate their core protocol we in Bitcoin don’t do the same. -
You say you "get that"... and yet you go on to say that you should be able able to get total issuances from blocks..... so not sure you DO get it... you can't determine if an issuance is valid or not until Counterparty parses it.
-
I’m talking about reading, not writing
-
I am talking about reading too
-
you can not read an issuance from the blockchain and determine based on just the blockchain tx if it is seen as a valid issuance by CP or not
-
Wtf?
-
seriously? You just said "i get that"
-
Isn’t that what the status: valid means?
-
and now your confused by "that"
-
valid bitcoin transaction DOES NOT mean valid counterparty transaction
-
Ok this is new to me. Please explain
EDIT: this reply was based on misreading the message as if it meant that status = valid doesn’t mean is actually a valid CP transaction -
the Bitcoin transaction may be valid... yes, it paid a fee and was mined, it is a valid REQUEST to counterparty to do an issuance..... but it is on Counterparty to take that REQUEST and determine if it is valid, using the internal CP state
-
I just explained it above quite clearly..
-
because the transaction in the block just says "This user says to transfer XCP from addressA to addressB"..... with no regard to if addressA actually has the XCP available in its balances to send.... Only AFTER counterparty parses the transaction and verifies that the user has the XCP in their addressA, THEN the XCP is debited from AddressA and credited to addressB..... so, you see, all Bitcoin does is hold requests for CP "move this, issue this, place this order".... Counterparty is what parses the transactions and determines their validity
-
please re-read that.... it is a PERFECT example of why you can't just read a transaction from the bitcoin blockchain and assume it is valid
-
Does address A have XCP to send? Lets verify..... Does address Y have the XCP in their balances to pay the issuance fee and make this a valid transaction? lets verify....
-
When counterparty parses in transactions, it does all sorts of validations and verifications on the transaction to determine if it is a valid transaction... Here is an example of an issuance transaction which failed.... it is a VALID Bitcoin transaction (it paid the miners the tx fee to get mined), but it is an INVALID Counterparty transaction (the issuer did not have XCP to pay the issuance fee at the time when the issuance request was parsed, so it is marked as invalid, and this asset WAS NOT ISSUED). The transaction was marked as 'invalid: insufficient funds' instead of 'valid' https://xchain.io/tx/2051665
-
Ok @jdogresorg I fully get that. But what I meant was valid inside the Counterparty message. Status = valid. The Bitcoin transaction being valid is a given (this is why I misread and answered “this is new to me”, as if you said that having status=valid doesn’t mean that is a valid CP transaction. Will edit that message…)
-
Makes counterparty very different from other token protocols on bitcoin like colored coins or rgb
-
You need to check every bitcoin tx to see if it’s a counterparty tx
-
Only then can you determine if a tx is valid
-
Can the _messages in get_blocks be relied on? Only considering the status:valid ones
https://counterparty.io/docs/api/#get_blocks
What does the timestamp in the message response mean, as the binding for an issuance?Counterparty API | CounterpartyDevelopers/API.md
-
Thanks again. I got those calls working fully now. Here's the latest version of my leaderboard if you'd like to see. This page shows all the holders so if you have any do a browser text search to find your address.
https://cards.bitcoincoaster.com/lb/ -
I think the misunderstanding came from thinking that I am actually parsing the raw bitcoin transactions. I’m not doing that, yet. I have always meant the messages as they are retuned by the get blocks CP api call. And only considering the status:valid ones.
I want to learn how to verify the ledger, txlist and messages hashes. Any good reference about this? -
You have always been able to setup multiple dispensers on the same address, it just is discouraged unless u know what ur doing👍🏻
-
DarkFarms uses the same address for all his sales and he's done a ton. He actually hosts the dispenser on his creator address. He usually does a 24 hour sale and then closes it down. And because of it you can see he's got over 4 BTC in his address from sales.
https://xchain.io/address/1DRZVQe58Tr9WxDNYdJUbye3toH1zkedX -
What do you want to verify? Txs already processed by CP? Or bitcoins txs that could be processed by CP? -
To start what has already been processed. The hashes from the result of get_blocks
-
correct
-
FYI... updating Counterparty on the xchain servers... the results may lag behind a bit... please use host1.xchain.io as it should be caught up 🙂
- 18 August 2022 (2 messages)
-
I have ESXi and a fiber connection on premise, should I self host a fed node or put it in the cloud? Suggestions, pointers, notes and criticism welcome.
-
you can prolly just host at home perfectly fine... just make sure you install ubuntu linux, have around 64GB of ram, and 4TB of usable disk space
- 21 August 2022 (7 messages)
-
GM 👋
-
Tried to to a schema comparing CP & ETH, could you tell me it looks ok for you?
-
-
-
probably lacked the fact the CP wallet is connected to a node API
-
Not bad👍🏻
-
thanks 👍
- 22 August 2022 (6 messages)
-
Very nice graphic. I would say one detail left is that CP_DATA translated in the CP node must be valid. As it was discussed a few messages back, the CP_DATA by itself is not enough
-
And by then the CP_DATA becomes 1+ “messages” in a block
-
i wrote a short medium post about the differences between counterparty and eth a few years ago
-
The Real Cost of Cryptogoods
The “realness” of these tokens is, in many ways, the most important facet to consider as both a token issuer and a collector.
- 23 August 2022 (10 messages)
-
Good read, thanks for sharing! I believe this is relevant with relation to CIP3
-
It’s certainly relevant for any consensus changing updates
-
I’ll add my thoughts to the CIP3 issue on GitHub tomorrow, was on vacation last week so didn’t have a chance to comment when it was being discussed here
-
some people might be surprised to find out that the asset description can be updated even after an asset is locked
-
changing divisibility also doesn’t change the nominal number of units of an asset but simply the lens through which the asset is viewed
-
Token name is most important and best part of Counterparty. Can't change the name.
-
Finally had a chance to comment if anyone cares
- 24 August 2022 (63 messages)
-
Joined. -
Posted on CIP 3 on GitHub
-
Kick activation block can, don't shoot network in the foot for no reason. State management across federated network of server is hard, don't be stupid.
-
Left.
-
Is this a critique of the proposal itself or of the process?
-
As a developer on counterparty for the last 8 years, I struggle to find the argument against cip3 and how it’s impact would be a negative to any current or potential future devs
-
Personally I was surprised to see the pushback as this is a relatively benign change compared to sweeps, destructions, dispensers and p2sh encoding all hardforks implemented over the last couple years
-
What issues have yet to be addressed?
-
This touches the point perfectly. All these hardforks brought new functionality and efficiencies that benefited everyone. CIP3 doesn’t benefit anyone actually using their assets. Is this “benign” frame that I have a problem with. If a change to divisibility handling wants to be done, which will affect current protocol level assumptions, it should be done in a way that benefits everyone
-
It benefits everyone, it is not a permissioned function
-
Multiple people in this chat lamented about how they accidentally issued divisible assets
-
Also you don’t always know what you’re going to do with an asset when issued
-
Sometimes you just buy a name because it’s topical
-
the idea that accidently creating divisible assets can be addressed with a UI enhancement .. making divisibility a mandatory user input that is not pre selected is a great idea going forwards , but cip3 benefits everyone who previously registered an asset incorrectly
-
Counterparty is good because it is unlike any other namespace as asset registrations are eternal and do not require renewals, we however are mere humans who make mistakes and like to change our minds, cip3 makes assets more flexible and more useful to both current owners and potentially future owners
-
Ok all these are valid points. But is the current CIP3 implementation the best one? Why do it in way that works like an UNDO, which from my perspective goes against what Bitcoin (and NFTs!) stands for.
Like one divisibility handling option that I think is more elegant is to allow the first issuance to NOT specify divisibility while the quantity is 0. Like making this issuance use case a “name registration issuance”. And I think it even makes sense to not allow a description either. Basically you are only allowed to do this “name registration issuance” once. Only transfers are allowed.
It has clear intent, and doesn’t break any philosophical properties of what blockchain assets should be.
And I am sure there are other alternatives to consider also… -
You do realize this suggestion is more complex, which was one of your concerns
-
I’m curious why changing divisibility is more “against what bitcoin stands for” then say creating additional issuance
-
Users already know to treat unlocked assets differently because issuance could change, although that’s not an issue with CIP3 because the issuer must hold the entire issuance to do it
-
An undistributed asset is not an immutability concern, it’s basically just a name registration like you said
-
I care about Bitcoin. I can’t see Counterparty fulfilling its potential without the support of Bitcoiners. We are all aware that many of these Bitcoiners don’t approve using the Bitcoin blockspace for anything other than financial transactions.
So, from my perspective, every detail matters. The Counterparty of today respects immutability. CIP3 removes it. I don’t see this as an improvement to help the protocol obtain approval of Bitcoiners.
As I say in the GitHub issue: “CIP3 breaks the simple cohesive elegant design of issuances and destructions.” -
CIP3 only works on unlocked assets so it also respects immutability as much as allowing additional issuance of unlocked assets
-
Exactly
-
Even more so since the asset must be undistributed
-
if you were to send some quantity of an asset .. and then have it sent back could you then CIP3 reset the divisibility? .. is the criteria owner must hold 100% supply or is it the asset must be undistributed?
-
100% of supply in one single address, the owners address
-
so, COULD be distributed, then all tokens sent back to asset owner, then reset... but highly unlikely that an asset owner would be able to widely distribute a token and then get control of 100% of the supply back
-
could do that pretty easily tho if we re-activated the callback feature 😛 J/K
-
👌
-
I actually liked the callback feature!
-
But that was before tokens were collectibles
-
I never used it, but it sounded like a cool feature... it was disabled pretty quickly
-
I used it for my fantasy league in 2014
-
oh ya? that is awesome! so you distributed your tokens, then called them back at a set XCP price?
-
No price, just called them back at the end of the season
-
Although in hindsight I left the other managers without collectable tokens
-
I’ll have go back and check I may have tested it preseason and then it was disabled at the end of the season
-
That was actually the first 1/1 I ever issued
-
FFLTEAMA
-
it should be noted that jdog did not propose CIP3
-
also not all of us that want it have a cache of old assets
-
this is a very old proposal
-
its not a new thing that has sprung up
-
so assuming its being done just because jdog wants to sell his old assets is a bit presumptive to say the least
-
ive yet to see an argument against CIP3 that makes any sense on a technical level, the arguments i see are disagreements with the process or with a perceived ethos
-
“Go for gold with CIP3 but I don’t think it resolves Jdog’s issue which is running an ecosystem in which people make massive profits, for free.” who exactly is making massive profits for free?
-
you mean “for free” as in they dont pay for development?
-
he’s just stating that he’s invested in the platform which is an incentive for him to stick around, just like a bitcoin developer owning bitcoin
-
i wouldnt want anyone working on counterparty thats not at least somewhat invested in its success
-
we’ve all been openly discussing juan’s issues with CIP3 and it turned into issues with counterparty culture, which is a fine thing to discuss but offtopic to say the least
-
juan is welcome to have his concerns but personally i dont think they rise to the point where CIP3 implementation should be derailed, then again im not the maintainer just another developer with an opinion
-
i dont think thats a fair interpretation of CIP3
-
if it was so important to jdog why didnt he expedite that CIP years ago
-
i think its a good discussion but rather than make assumptions we should look at things objectively
-
CIP3 is objectively good for asset issuers because it gives them more flexibility
-
i also agree with your point that it can be very frustrating as a developer of an open source project when its difficult to find funding especially when its generating a lot of value, but many of us stick around primarily because we love Counterparty and are proud of what we’ve built and as frustrating as it can be sometimes its also extremely rewarding to see it as successful and influential as its become
- 25 August 2022 (81 messages)
-
CIP3 is objectively bad for Counterparty as a developer platform, as for a very limited use case divisibility and destructions become more complicated to understand and code.
CIP3 is objectively bad for Counterparty trust, as an immutable property has become mutable.
CIP3 is objectively bad for Bitcoin, as it promotes NOT committing to actions done on assets, it promotes UNDO behavior in a very scarce resource.
CIP3 is so old it doesn’t even consider the existence of destroys. Why not solve divisibility problems with a new CIP that considers CP in its present form?
I am sure there can be a better implementation for the biggest problem which is not having to commit to a divisibility if someone just wants to reserve the name. And I am almost sure it can be done in a way were ALL 3 of the negatives above can be avoided. -
Destroys were around prior to cip3 then removed from the protocol then readded years later
-
That’s interesting then, good to know
-
As a developer what exactly is wrong with CIP3, I’ve built more wallets than probly anyone in counterparty and I can’t think of any I’d need to change as a result of this
-
Especially if divisibility is added as a returned parameter in the get_balances call
-
Generally I just look up the most recent issuance to pull divisibility and description
-
That would not change
-
Bad for counterparty trust is also a weird thing to say because a token issuer can choose any parameter they want, we’re talking about unlocked and undistributed tokens, there are no expectations from any other user besides the issuer
-
Bad for bitcoin? I guess you’d say that about any consensus change to counterparty of which there have been many
-
Your final suggestion is to make a weird pre divisible asset state which would be a much larger deviation than CIP3 and add complexity, which was one of your initial complaints
-
Raised a couple issues on github.
Tldr, i believe we can remove some deadweight (callability) from issuance, thus add 9 char to max description to fit op_return. Perfect time now as we modify issuance anyway. -
Joined. -
Anyone know why a mobile address would show different assets than a desktop? -
Seems someone sent a fakeasf to a new artists wallet last night and it doesn’t show up on the desktop but does on mobile
-
It’s the same address and all other assets are showing
-
It’s like the desktop is behind for some reason
-
Desktop is behind. It depends on which server it gets the info from. I'm seeing funny things too
-
Ughh what a time for this to happen to one of the biggest artists in the world and he has a shitty experience lol
-
one server is behind... host2... working on catching it up
-
Ok
-
Any ETA?
-
its only about 50 blocks behind... so prolly 30-60 minutes
-
Ok thanks a lot jdog
-
yep... sorry for the issue... been trying to quietly update a bunch of servers in prep for the new 9.60.0 release coming in a day or two.... but, clearly one of the servers hiccuped
-
I stopped apache2 on that host2 server... so it should be removed from the load balancer (ie, you should only get good results now)
-
Thanks bro.. appreciate it
-
-
@hodlencoinfield callbacks were setup so that you had to issue set the callback date and price at the time of issuing supply yes? Could you change it after the first issuance (like, after you called all your tokens back, could you do another issuance with a different callback price/date
-
thinking about reactivating it again if the community is supportive..... I mean, we're holding 10 bytes of data in every issuance tx for the callback data.... should either re-activate it, or free up those 10 bytes for use in asset descriptions (JP brought up this suggestion on the cip repo)
-
Reset as a parameter or keyword? · Issue #55 · CounterpartyXCP/cips
If I understand the Dogeparty implementation correctly, RESET is a new parameter added to the issuance message: This comes with some negatives; not backwards compatible (e.g. javascript libraries n...
-
tbh im with JP on just removing it
-
its been deactivated for a REALLY long time.... you remember the reasoning behind deactivating teh feature?
-
i think its confusing and no one was using it
-
now that tokens are 99% used as collectibles i dont think it makes much sense to bring it back now
-
better to reclaim the 10 bytes of data
-
ok... i'll add it to the todo list.
-
it is da wei
-
its all part of the counterparty experience
-
It really be like that
-
Decentralized platform... centralized block explorer.... more block explorers == this happening less often... cmon guys, share the burden, someone write another block explorer 😛
-
Hey J-Dog, I'm running a script in PHP that hits the xchain api to get balances of each holder of my cards (around 200 addresses now). Is there a target rate of request I should go for? Right now I have my script pausing inbetween calls, but not sure what's best. I'm only going to run the script 1-4 times a day
-
pausing 1 second or so in between calls is fine
-
I heard this is happening
-
right now I have no rate limiting.... which is allowing ppl to just beat the shit out of the APIs and abuse them.... in the coming month or so I will focus on getting some ratelimits enforced (cloudflare charges you per-request, so I was trying to avoid doing this as it incurrs even more operational costs... but, I think its getting close to the point where I need to... it willl reduce the load on the existing servers, and rate-limit the abusers..... might offer a "premium API" service which is not rate-limited for a monthly fee... but for right now, 1-2 second sleep in between requests is plenty conservative enough 🙂
-
awesome news! I look forward to it... I am working on a new block explorer myself, but it'll be a few months before it is ready/released
-
what doers it cost to maintain a block explorer? roughly
-
depends on how popular it is... xchain is pretty popular cuz of its APIs which power a bunch of apps and wallets.... right now xchain runs on 5 servers (!$250/mo x 5 = $1250/mo)... and xchain runs on cloudflare which is about another $250/mo.... and that doesnt include the actual time/money to maintain/update/tweak the explorer..... Honestly, costs about $2k/mo plus about 15-30 hours/mo of dev time/work
-
Ok good to know
-
for just a normal block explorer without APIs that everyone calls on... could prolly run it pretty well on a single server for quite a while.... xchain was running on a single server for 6+ years... it was only after the last growth explosion last year that we needed to upgrade to 5 servers.
-
I have some dev funds still if anyone makes a good block explorer and could prolly donate fir the first year of operation as long as the builder agrees to maintain it for at least 5 years
-
i heard the new explorer is called explaryan
-
-
This release includes CIP3?
-
Yes, as well as a bunch of other updates
-
Wow
-
Not sure why that is a suprise. I indicated in the issue you raised on github that CIP03 would be going forward. We have heard your objections to the proposal... at length... numerous times... and while we appreciate your feedback and opinion, CIP03 is moving forward, as it is an improvement which the community has been waiting on for 8+ years.
-
Wow again 😂
-
Where is the consensus of the decision of the activation date /block? I see in the GitHub @droplister asking for the activation block to be moved into the future… I still see alternative implementations being proposed by @jp_janssen… Where was the discussion for the different alternatives of implementation?
-
There are approximately 10-15 servers running counterparty nodes, of which we are running 10, exchanges are running 2, and a few community members are running some, and they will all upgrade very quickly when we put out the release. @droplisters concerns about activation block were because he thought that there were API changes which would require 3rd party apps to make updates, but that is not the case. @jp_janssen's suggestion is being worked on and implemented into this new release as well... to remove the callable/call_date/call_price fields from issuance data.
-
the activation block will actually be sooner than 2 weeks, as we want the new features to go active quicker, so that we can sus out any issues on mainnet later next week.
-
The only reason not to have a quick activation is if there were a large community of users running fednodes, and they all needed time to update, that is not the case here.
-
I have a fednode.
I guess the biggest problem I see is that critical decisions and changes are being done “quietly”.
And then you make a message about being a “decentralized protocol”… really??
@jdogresorg you have done great service to the community. But I really believe you are dropping the ball in handling this -
Your misinterpreting quietly as something nefarious.... what I meant by quietly is that I was not announcing that I was updating the xchain servers as I have in the past, and telling everyone to use host1.xchain.io.... not that something secret was going on.
-
Ok but it means those nodes are already running 9.60?
-
no
-
Ooooh ok. It seemed like that was the case
-
in the past I have updated multiple servers at the same time... I was rolling out some changes to one of the servers and updating the counterparty version with support for oracled dispensers, so I could test some code changes on xchain
-
no... there is no 9.60.0 release yet... it is pending, and will be announced before any servers are updated.
-
Ok now I have the following question, have there been people that refuse to make updates in the past? Effectively the people upgrading are the ones doing the hard fork… what has happened?
-
AFAIK No one has publicly stated that they have done this, everyone upgrades and runs the new version.
-
🤔
-
Unable to perform asset reset · Issue #8 · DogepartyXDP/dogeparty-lib
I am using the below json to make an API request to the CP API, then signing and broadcasting the transactions, but unfortunately dogeparty does not appear to be picking up the transaction. { &...
-
Yes, they are working on dogeparty... there was a minor issue with certain asset resets not working (if the asset has been reserved, but no supply had been issued)... the issue was fixed in Counterparty CIP03 PR, and fixed in dogeparty. https://github.com/DogepartyXDP/dogeparty-lib/pull/9Fixed ignored resets because of incomplete balance query by pataegrillo · Pull Request #9 · DogepartyXDP/dogeparty-lib
Dogeparty Protocol Reference Implementation. Contribute to DogepartyXDP/dogeparty-lib development by creating an account on GitHub.
-
is the ask here to just bring up another xchain instance (is it OS) but manage the code and fork it (think not) or code a new explorer from scatch that has the same functionality of xchain?
-
new explorer from scratch would be ideal... we need a few different ways to view the CP data... and to decentralized the block explorers.... xchain is ok, but its more like a big database viewer (lots of tabs with lots of data).... i'm working on a streamlined explorer (tokenscan.io) which shows much less unnecessary data.... but yeah, the more block explorers and ways to view CP assets, the better
-
ok, would it need to access it's own Fed Node(s) (I assume yes)
- 26 August 2022 (10 messages)
-
Fednode querying would be slow… better to use counterparty2mysql as it has all the addresses, assets, and transactions indexed, so faster than the SQLite tables that CP uses internally
-
Nope, never installed on arm cpu
-
Can you expand on this thought when you get a chance.
-
Counterparty internally uses a sqlite database to store its data and anytime it needs to write an asset name, an address, or a transaction hash to a table, it writes the entire thing. The end result is that the same asset/address/tx_hash can be written many times bloating the database. Plus the queries you do to CP are quite often are full-table scans (meaning your doing an actual text match row by row instead of benefitting from a fast index)..... Counterparty2mysql is a tool I wrote years ago to take the data out of Counterparty and put it into a mysql database, except I index (assign a unique number) every asset/address/tx_hash, and use that reference number in my tables instead of the full asset/address/tx_hash.... makes queries much faster since it benefits from a small/fast index vs full-table scan matching.
-
Eventually, Javier and I would like to move from sqlite to a mysql/mariadb database for internal use and retool the database tables/indexes a bit... but its a big undertaking, so it prolly wont get done for a while
-
GitHub - jdogresorg/counterparty2mysql: PHP script that populates a MySQL database with Counterparty data
PHP script that populates a MySQL database with Counterparty data - jdogresorg/counterparty2mysql
-
This is a wonderful idea. I just read through and cp2mysql is going to make sandboxing so much easier and more enjoyable. Kudos.
- 27 August 2022 (27 messages)
-
https://swagger.io/tools/swagger-ui/ This link is not exactly db related but I wouldn’t do that without doing swagger first, if I were you two. My two sats.REST API Documentation Tool | Swagger UI
Swagger UI allows development team to visualize and interact with the API’s resources without having any of the implementation logic in place. Learn more.
-
The documentation and such generated by swagger can help by having a great reference and plenty of copy paste ammo. I don’t know if swagger is compatible with their setup or not but it is has been a nice reference tool for me in the past for similar tasks.
-
I think I saw a post a while back about a new guy working for counterparty for documentation and such. Maybe pass it along to him, or was that you?
-
@jdogresorg some of my sub-assets now show up as those free assets that start with an A? Super weird assuming its some bug or something?
-
ahh ok thanks! is the new update to freewallet safu?
-
I downloaded it but havent installed it yet
-
subassets technically are numeric assets
-
with a second name
-
yep, just throwing that out there in case people didnt know
-
These sub-assets even showing up wonky on xchain
-
-
never seen that before
-
If numbered assets are free regarding XCP, why not sub assets?
-
the assets are free, the custom name is not
-
docs.counterparty.io
-
what assets are you having issues with?
-
can you link me to a subasset name please
-
Thanks. I really value the time and headache savings it provides for all developers and has provided me in the past but after thinking about it more, at this point Swagger is probably more useful to @jdogresorg re his next explorer but it would bring value to the cp server api as well (what I was referring to). It’s almost one of those things that is best if implemented from the beginning instead of with a finished project but utilities can make the workflow go both ways.
- 29 August 2022 (30 messages)
-
Release v9.60.0 · CounterpartyXCP/counterparty-lib
This release contains a number of bug fixes, updates, and new features. Removed callable,call_date, and call_price from issuances - [more info] Added support for CIP24 (Oracled Dispens...
-
FYI... just put out the 9.60.0 release.... am in the process of upgrading all the xchain and API servers to this new version... then will focus on getting this release announced on the website/twitter/newsletter
-
went with activation blocks 2 weeks out to give ppl time to upgrade (even tho I think this time is unnecessary, I want to error on the side of caution)... activation block for new features is 753500 (~2 weeks)
-
out of interesst what is the new size in chars a description can be yet still use an OP_Return and not need multisig encoding?
-
CIP13 (CIP3 alternative): Divisibility set by defining the asset, not by reserving the name
Counterparty is about to make a change that I believe goes against the principles of Bitcoin, CIP3. For Counterparty to reach its maximum potential, it needs to win over the approval of most Bitcoiners. Many of these Bitcoiners believe that the blockspace should only be used for financial transactions. So, in order to gain their support, every detail matters. CIP3 has always been framed as a “benign” change that won’t affect anyone. But this is only because it was rationalized from the perspec...
-
Direct link to the CIP: https://github.com/jotapea/cips/blob/cip13/cip-0013.mdcips/cip-0013.md at cip13 · jotapea/cips
Counterparty Improvement Proposals. Contribute to jotapea/cips development by creating an account on GitHub.
-
where can we read up onn cip24 ?
https://github.com/CounterpartyXCP/cips does not show it
who runs those vanity addresses posting btc prices as memos? and how is btc price calculated?GitHub - CounterpartyXCP/cips: Counterparty Improvement ProposalsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Yeah... CIP24 was written by John before he died and was still in idea phase, it never really made it into its final form an was commited to the CIP repo.... we'll be updating the CIP to match the code in the coming weeks.... but basically... oracles broadcast the price via broadcasts periodically and charge a usage fee... when you create a dispenser, you can choose an oracle, which will allow you to price items in the oracles fiat unit USD, JPY, EUR, etc..... the Counterparty system then uses the oracles broadcast price to determine how much BTC needs to be sent to match the sellers desired FIAT sell price (like $20) and trigger a dispense.
-
-
there is a dispenser on testnet that sells for 10 JPY
-
I really like the idea of oracled dispensers . it makes things a bit easier for normies to grok if you can sell a token for $x
-
so we will be able to query the counterparty api to determine how much btc is needed to trigger a dispense ?
-
Yes, you can get that info directly from Counterparty API via the new get_dispensers_info() API call https://counterparty.io/docs/api/#get_dispenser_infoCounterparty API | Counterparty
Developers/API.md
-
satoshi_price is the field your looking for 🙂
-
xchain APIs have also been updated to pass satoshi_price 🙂
-
-
-
what happens when mempool gets flooded and a tx may be delayed? is there a built in % for slippage that is allowed for ?
-
All Dispenser payments should always be sent with a high tx fee.... but yes, we honor price for up to 1 hour after oracle has broadcast a new price
-
6 blocks
-
After freewallet updates, next up is Trusted Dispensers... where dispenser operators self-identify themselves... should help solve some of the trust issues with dispensers and not know if your gonna lose funds if someone frontruns a tx on ya, etc.
-
OK thank you .. is good to know how it works .. lines have to be drawn with these type of things and 6 blocks/1hr is a fair place as mempool flooding can result in lengthy delays but btc price changes rather quickly too.
-
This CIP tries to accomplish what was mentioned in this message. I understand that the CIP3 release is already started to be promoted, but if this is really a decentralized protocol, then all proposed alternatives should be discussed…
-
I would really appreciate some feedback
-
-
IMO Overly complicates an already functioning asset system. Also, please review CIP1 and CIP8 for info on the proposal process. First there has to be discussions to determine if the community likes the idea before spending the time putting forth a CIP, defining development milestones, etc.
I’m glad your here and eager to contribute, even if we don’t agree on some features/points, but please try to follow the defined processes laid out by the community. -
Good point, but I had the draft ready and saw the 9.60 release announcement so I just put it out. Is not like i have the luxury of time for this one 😉
-
Well I don’t think it complicates it more than CIP3. Unless you mean making this in addition to CIP3, which is not its purpose. My proposed CIP13 is a replacement for CIP3
- 30 August 2022 (16 messages)
-
1.6 million blocks... yeah, thats def not normal 😛
-
Anyone else getting this error trying to sync counterblock testnet with fednode?
-
correct... new version of counterparty-lib is up on github
-
yup.. seeing that too... will work to get it fixed
-
just pushed out an update which fixes this issue.... running the following commands should get counterblock parsing past the issue `fednode update counterblock counterblock-testnet;fednode rebuild counterblock counterblock-testnet`
-
FYI.. just pushed one more update to counterblock which fixes a separate issue on mainnet... after these 2 fixes, parsing on mainnet/testnet resumes and completes
-
Joined. -
federatednode/bitcoin.conf.default at master · CounterpartyXCP/federatednode
Federated Node Build System. Contribute to CounterpartyXCP/federatednode development by creating an account on GitHub.
-
Counterparty needs a full node, pruned won’t work
- 31 August 2022 (22 messages)
