- 01 November 2023 (101 messages)
-
so I don't sign the second tx but transplant the signature from the first ? -
the api should sign the 2nd i believe -
or i should say, create a valid signature with the message data
-
the api gives me unsigned hex for the second tx .. well coinb.in reports the hex is unsigned
-
i’ll take a look, been meaning to start looking into adding multisend to rpw
-
ok ty.. mempool.space reports mandatory script flag failed operation not valid with the current stack size .. so the api generated 2nd tx hex is missing a something
-
yes... have to sign/broadcast the first p2sh tx before you can generate the second tx.... need the tx_hash from first tx for`p2sh_pretx_txid` param in the second tx
-
second p2sh call is EXACTLY the same as first except I give p2sh_pretx_txid
-
yeah I did that ... and the second tx needs a signature on the p2sh address that is the output in the first tx and becomes the input we then spend in the second tx
-
weird i would think that would generate the signed tx since there’s no change output
-
I have a 546 satoshi outtput in a address starting with a 3 that goes to miner fee for the opreturn but I can't broadcast a unsigned tx
-
well you’re spending all the p2sh outputs from the first tx, oh maybe it does have a change output
-
no change output
-
it's just the one p2sh input and one op return output
-
your 1st tx had just a single p2sh output?
-
yeah was a multisend of 1 card to 7 addresses
-
ok then the api should be creating that signature, maybe there is another flag
-
all that signature is is the hash of the script that contains the message data
-
1st tx has 2 outputs the p2sh encoded data and change
second tx has no change -
yes
-
thats how it should be
-
hmm api not creating signed tx hex for the second part
-
trying to sign second tx hex with the private key of the source address from 1st tx does nothing
-
it wouldnt
-
that 2nd tx doesnt have any inputs that need to be signed from the address that created the 1st tx
-
I need the key to the address starting with 3 that contains the dust to be spent
-
no
-
it is a p2sh
-
you need the script that hashes to the value that makes it true
-
ahh
-
which is your message data
-
which is why the API should create it, i think maybe there is just a flag you’re missing in the api call
-
that makes sense
-
as yeah I am feeding the api the txid of 1st part of the 2 step process but not getting back signed stuff
-
counterparty-lib/counterpartylib/lib/api.py at c7b8995b5a11e42ea86222f7b3f1881d01c2fdd0 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
there are some tests too, https://github.com/CounterpartyXCP/counterparty-lib/blob/c7b8995b5a11e42ea86222f7b3f1881d01c2fdd0/counterpartylib/test/p2sh_encoding_test.py#L130counterparty-lib/counterpartylib/test/p2sh_encoding_test.py at c7b8995b5a11e42ea86222f7b3f1881d01c2fdd0 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
did you broadcast the 1st tx yet?
-
if not i think you should be able to create your own utxos to feed to the 2nd tx using the custom_inputs parameter
-
you probly also need to set allow_unconfirmed_inputs to true
-
not sure if that’ll throw an error if the utxos you’re using arent in mempool
-
I did broadcast first tx
-
I got confirms too .. but yes unconfirmed inputs is helpful whe not wanting to wait for 1st to confirm
-
hmm
-
im looking at freewallet repo now
-
when I use "extended tx info" the second tx shows 'btc in' as 0 but 'btc out' is 546 ..change is null and btc fee is 0 ... which adds up .. the 546 from the script becomes the miner fee .. and there is no change
-
If I don't have 'encoding' p2sh the api generates a bunch of multisig outputs even tho I specify the p2sh prextx txid .. so I am confident the p2sh encoding is required for the second tx
-
i found it
-
one sec
-
looks like you do need to sign
-
The API always generates unsigned transactions… there is no way for it to ever generate a signed transaction since there is no way you can provide a private key to the counterparty API -
yes i think i just wasnt fully understanding p2sh encoding
-
apparently there is a signature check
-
The second TX in a MPMA transaction just references the first transaction, and the second transaction gets all of the data from the outputs of the first transaction as the inputs of the second transaction
-
it actually recreates the data, because the outputs in the first tx are just hashes essentially
-
so how to derive the private key to sign with ?
-
freewallet-desktop/js/freewallet-desktop.js at master · jdogresorg/freewallet-desktop
Desktop wallet for Win/Mac/Linux which supports Bitcoin and Counterparty - jdogresorg/freewallet-desktop
-
that has the info you need if you’re using bitcoinjs-lib
-
ty that helps .. i will see if I can get it working from there
it seems to take the private key from the source address and then augments it using CWPrivateKey
privKey= getPrivateKey(net, source),
cwKey= new CWPrivateKey(privKey),
keyPair = bitcoinjs.ECPair.fromWIF(cwKey.getWIF(), network), -
its just a util function, you should be able to use the WIF you generate using bitcoinjs-lib
-
so is it kinda using the private key from the source address that was declared when creating the multisend ?
I have that private key in WIF format that I derived from users seed using bitcore and mnemonic-1.1.0.js .. will try passing that into a sign function see I can get the second tx broadcast -
yes.... same private key that signs the first tx signs the second tx
-
yeah i just misunderstood how the p2sh encoding works in that there is a signature from the original address
-
along with the message data that altogether forms the script
-
all makes sense
-
i do wonder if you can use the custom_inputs and allow_unconfirmed_inputs to create the 2nd tx without broadcasting the first
-
yay that worked .. thank you both
-
I have broadcast a signed second part tx .. just got to wait for my 1.3 sat byte tx to confirm
-
I was trying to add custom input to the second tx to try n force a change output so a multisend could be cpfpd but the cp api just ignores custom inputs when creating 2nd part tx
-
ahhh ok, good to know
-
for Freewallet i usually send users to this FAQ:
https://gist.github.com/davestaxcp/1e2cc086a13c9a2d045876852b57e5be#failure-to-send-not-enough-btc-in-walletFreewallet FAQ 2023 v0.9.23 - Write Up - Draft #5Freewallet FAQ 2023 v0.9.23 - Write Up - Draft #5. GitHub Gist: instantly share code, notes, and snippets.
-
MOST likely its because you have too many UTXO's on your addy
-
gotta consolidate them by sending all the BTC you have back to yourself
-
turns your bag of coins into one single bill
-
theoretically speaking
-
HUH
-
well thats all i can give with my expertise... would love to know the answer when you find it
-
sometimes just a restart of Freewallet or your computer helps
-
or using a VPN
-
interesting
-
probably because the change is smaller than dust... so CP throws error instead of just using the extra sats towards the miners... should be fixed in the next release
-
Send change smaller than DUST to miners fee instead of error by pataegrillo · Pull Request #1228 · CounterpartyXCP/counterparty-lib
This fix adds a new parameter dust_size to the backend utxo sort function in order to change it from DEFAULT_MULTISIG_DUST_SIZE to DEFAULT_REGULAR_DUST_SIZE depending if the tx uses a "multisi...
-
big
-
yeah, way more than dust... so maybe throwing the error for some other reason
-
-
-
CP API returning tx sometimes and other times that balance error... short-answer, try it a few times and it'll go through... long-answer, we still got some issues with CP API and balances sometimes it seems.. prolly addrindexrs choking and returning a bad response... wil need to dig into it 🙂
-
no difference at all... same exact request, same exact API
-
-
it would be cool to have an assume_valid_utxos parameter, then we could use custom utxos and avoid even hitting addrindexrs or bitcoind
-
just check to see if the custom_utxos is formatted properly and skip all the other checks
- 02 November 2023 (48 messages)
-
This is a periodic warning to be on the lookout for scammers and fake accounts impersonating known OG's.
A reminder to everyone to be on their guard.
Active scammers in the community have now captured well over $200,000 USD worth of assets from multiple community members across the past year or so.
If someone comes into your DMs looking to do any OTC deals, and you're not 100% sure you are dealing with a trusted counterparty, please please please verify their bona fides with one of the key group Admins / OGs.
As always, I'm available to provide escrow services on all high value deals.
$250 USD up to $50K value exchanged, then 0.5% of total deal value above that. -
Try adding the fee field at 1 sat.
I often have this issue and fix it by manually substracting the fee after using a tx editor.
CP automatic fees look random to me.
If you don't have a tx editor, maybe try with 3000, should pass ok for a simple send.
Also you should consider start using segwit (bc1xx), most tx are 40-100% more expensive in legacy (1xxx). -
Joined. -
Joined. -
Joined. -
I notice your not specifying a fee either as a amount of sats or as fee per kb, so your leaving it to the cp api to decide, what happens if you explicitly state a fee ? either as a number of sats ? or as fee per kb
-
Even with fee: 1 ?
-
I just found that you can do a multisend using the api not using p2sh encoding, Counterparty then falls back to multisig encoding, so it's done as a single transaction. You can then spend the utxos created back to yourself 👍
this method also makes it possible to perform cpfp on your multisend -
does the MPMA parse fine without it being the 2 tx p2sh encoding?
-
i've only ever done it with p2sh encoding (as instructed by john)... never even tried forcing a different encoding method... is that all your doing? changing encoding from p2sh to multisig?
-
but how do you control the size of the output in step1 tx for p2sh, my multisend only creates a dust amount 546 satoshis .. which then results in a 1 sat byte part 2 .. I want more satoshis to use as fees in step 2
-
I don't know will broadcast a tx to try it
-
Afaik with mpma, CP only checks out second tx. First one doesn't have to be confirmed
-
The one with your addy as input could even be cancelled after the second is confirmed
-
I was trying to change the 'dust' output size in the step 1 of 2 p2sh method and I omitted the p2sh flag in the api and was returned a multisig encoded hex
-
p2sh and 2 txs is def going to be cheaper than multisig... but, curious if a single MPMA send using multisig works... pls report... my gut says CP will just ignore the tx... but would be good to confirm 🙂
-
And multisig is default on multisend
-
I happy to use the p2sh method but want to create 3addresses with more than 546 satoshi for encoding
-
so that when consumed in step 2 I can have more than 1 sat byte
-
eh.... second tx uses the outputs from the first tx as the inputs for the second tx....so dont see a scenario where tx 2 confirms but tx 1 doesnt.... since tx2 depends on outputs from tx1.... if tx1 is never mined, those outputs never exist, so tx2 cant exist
-
could be wrong... has happened a few times before... but, pretty sure MPMA p2sh always has to be 2 txs and both have to confirm
-
specifying multisig_dust_size should allow you to tweak the dust amount in the putputs
-
If you can't measure the fees youhave to put on tx 2, won't be that cheaper if you can't guess the fees you have to put.
Maybe I haven't digged enough to understand it -
Don't know how but I'm sure to have seen this.
-
nope ..my 3address output in step is is still just 546. I am sending 1 card to seven addresses so it is a small payload but I really do need to be able to control the dust so can control the amount of sats used as fees in step2
-
As tx1 can be bigger than tx2, and they don't look to be linked with cpfp (even if using output1 in input2).
In that case tx2 is more likely to be confirmed first. And there, I've checked CP API before tx1 confirmed, and saw assets sent as they should. -
please demonstrate this behavior.... fail to see how tx2 can even be generated without tx1 existing.... maybe your finding something new taht CP does... but in my experience, I have not see the behaviour your talking of.... and fail to even understand how that would work.... a tx which references another tx which is not mined... look forward to more tech details once you figure them out 🙂
-
we'll (probably) be switching to taproot encoding for MPMA soon (cheaper than p2sh)... so could be a moot point in the near future... but still will be good to know/confirm 🙂
-
Hrm.... so multisig_dust_size is being ignored and the default (546) sats is being forced instead?..... good to know.... if you could be so kind as to create a github. issue for this, we can get this fixed in an upcoming release.... you should be able to control the dust amount in those outputs with that param
-
I have also tried "regular_dust_size" but my p2sh output is still just 546 satoshi
-
Wasn't a tx I own so will be complicated to find it back. But definitely will spend time some day to find them back, confirmations are written forever
-
yeah.... we prolly have it hardcoded in the code... need to fix that
-
do we need a p2sh_dust_size param?
-
I will open a issue
-
IMO coming up with a general dust_size param is better than a custom param for each encoding type {regular,multisig,p2sh,taproot}_dust_size
-
should prolly normalize that across all API requests... not make it encoding type specific 🙂
-
multisig encoding dust is a little different to normal dust, its harder to spend 😂. Is dust still used when transferring asset ownerships? or did enhanced send remove all that dust that used to be sent ?
-
a transfer is an issuance not a send and it's been a while .. it used to create 5460 dust outputs
-
yes, we still use dust and the first output for issuance transfers
-
-
Blockstream Block Explorer
Blockstream Explorer is an open source block explorer providing detailed blockchain data across Bitcoin, Testnet, and Liquid. Supports Tor and tracking-free.
-
first output is the transfer_destination address and 546 dust
-
ahh .. is it dust output size that is used to send btc along with an asset in classic send?
-
I believe that’s the trick👍🏻
-
Good to know ty
- 03 November 2023 (2 messages)
-
Hey, anyone knows why CP doesn't look to want to create a tx using 546sats utxo?
- 04 November 2023 (1 messages)
-
I made a tx that created a 546 sat utxo and then another tx that spends only the 546 sat utxo .. which means I got a long wait in mempool for my 1.3 sat byte tx to confirm as I can't cpfp
- 05 November 2023 (1 messages)
- 06 November 2023 (1 messages)
-
- 07 November 2023 (15 messages)
-
in development for use with XCP
-
cips/cip-0030.md at master · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
What Is Taproot and How Does It Benefit Bitcoin? | River Learn - Bitcoin Technology
Taproot is an upgrade to Bitcoin which introduced Schnorr signatures, Pay-to-Taproot (P2TR) outputs, and new scripting capabilities. P2TR outputs offer great privacy improvements and enable Merkelized Alternative Script Types, a way for bitcoin to be locked to multiple scripts at once.
-
looks like Freewallet dot io is the only wallet preparing for this address and functionality addition from my knowledge
-
they are two entirely different addresses and transaction types
-
XCP uses the OP_RETURN function
-
you wont be able to even use taproot on a legacy or segwit address
-
(from my knowledge of the tech) - someone chime in if i am wrong
- 08 November 2023 (2 messages)
-
@krostue id love to know if others are
-
but first I've seen taproot evidence of future use is in v 0.9.25
- 10 November 2023 (7 messages)
-
this is a decentralized system and anybody who owns your token can sell it in many places however they like.... you cannot "ban" people from selling something once they own it
-
as for Token to Token trading on the Counterparty DEx you can read about how to do that here:
https://gist.github.com/davestaxcp/1e2cc086a13c9a2d045876852b57e5be#starting-an-exchange-pair-that-has-no-orders-up-yet-on-the-dexFreewallet FAQ 2023 v0.9.23 - Write Up - Draft #5Freewallet FAQ 2023 v0.9.23 - Write Up - Draft #5. GitHub Gist: instantly share code, notes, and snippets.
- 13 November 2023 (7 messages)
-
Hi there look to be an issue with MULTISEND in counterparty api.
It happens when you try at least 2 recipient multisend with one with BTC.
for instance 2 different recipients, sending BTC.
Note it happens with 1000x enough BTC.
Any insight? -
Multisend meant for sending assets not btc…. Pls create a GitHub issue for this n we can look into adding support for multiple btc outputs
-
This may seem like a silly question but just want to check something ...
Counterparty uses the same private key for Segwit (addresses starting bc1) as it does for Legacy (addresses starting g 1) does this mean it uses an identical public key? -
I think it's does but i just want to be sure
-
I know compressed vs uncompressed addresses come from same private key but the public key differs
-
yes same public key
-
ty
- 15 November 2023 (18 messages)
-
where do you have all this tokens ser? -
why host2.xchain.io and xchain.io are not showing the same info?
-
-
Joined. -
I'd like to start automating some of my addresses/inventory asset data updating in excel or google sheets
Can anyone point me to any scripting or automation methods for pulling the current contents of an address into a google sheet or excel sheet, or just a CSV would be fine. -
i believe excel added python support so maybe you can call xchain api with it and upload balances
-
is a cool project i wanted to do it some time ago before python update but i didnt know anything about excel but now with python is other thing
-
You mean just to see aggregated xcp balance?
-
full list of all assets and asset balances, so I can manage all my addresses/assets inventory
-
Depends on how many assets you want but you can use this https://xchain.io/api/balances/ADDY_HERE
And if you need more data per addy:
https://xchain.io/api/balances/ADDY_HERE/2
https://xchain.io/api/balances/ADDY_HERE/3 -
my largest address has 1415 different assets currently
-
so I need a simple python or javascript to loop through those pages till the end, pulling into an excel or google sheet, or a csv text file
-
Also depending on why you need the data, you can use https://wallet.xcp.ninja
=> create a fresh wallet (you can use your passphrase but not recommended)
=> add all your addies in read only
=> group them
=> select the group and check your balance -
but I'm an almost no-coder ... I did university assignments in Pascal, Eiffel, Miranda, C in the early 1990's and a bit of PHP early 2000's... but I've not coded anything in 20 years
-
I need ongoing live balances of all assets across multiple addresses
e.g. query: how many BERNIEPEPE across 20-odd addresses -
so one model could be a sheet per address, with a master sheet that aggregates all in a table ... I'm pretty good with excel, but getting the data into sheets with regular update, like a daily cron job, is beyond me without some help :)
-
other option is running a full counterparty node and getting an SQL dev to build me some kind of DB front-end in Postgres or similar.... which is what I had under development in 2021, including auction automation in a bot, about 2/3 of the way to working deployment
-
but that's all written in Flutter/Dart, which I don't know at all
- 16 November 2023 (15 messages)
-
so I have either a very small utility project, or a very large platform development project to resume early next year, subject to seed funding
-
depends whose asking :)
-
@hodlencoinfield I’m blanking on his name, but the old LTB dev built something that did this exactly, and if I recall correctly, if you had the BOOKKEEPER token you could use his service that gave you an XLS file for a given address. Not that it helps now, unless anyone has his contact info and he cares to help out. -
Ah I vaguely remember that
-
What RPT is asking for tho you could just ask gpt-4 to build
-
@rarepepetrader is the one who seems to need this, I was just recalling that memory
-
Devon Weller? Think I remember that product…. Was under tokenly umbrella…. He used to do a bunch of dev on cp….. til some community members attacked him for doing dev work….. threatened to sue him for working on hobby projects (bitcoin cash fork drama)…. So he noped out…… gotta always remember devs dev cuz they love to dev…. If dev becomes un-fun or ppl get attacked for doing work…. Eventually devs move on to other projects….
Protect n defend ur devs 😜
</end rambling> -
Actually, not Devon, but CryptoNaut, or something like that (forget his real name). I didn’t know that happened to Devon though, that sucks.
-
Ahh my bad memory😜
-
Lots of unknown community drama over the years…. We try to minimize it n stay focused on the prize tho cuz that’s what really matters…. Progress not squabbling 😜👍🏻
-
No, your memory might be right, there were two devs.
-
Devon was really good. Anyone still in touch with him? -
I would love this too
- 17 November 2023 (27 messages)
-
has anyone ever opened freewallet on osx and had everything gone? looks like a new install with no addresses? -
Sounds like freewallet data directory (where user-specific data is stored) got wiped.... on mac the path is ~/Library/Application Support/FreeWallet/Default
-
named assets are all uppercase and 12 letter maximum. Subassets are upper and lowercase and 256 character maximum
-
you also cannot start an asset with the letter "A" nor can you do an asset less than 4 letters
-
though, with BTNS you can
-
which is a new token naming system using broadcasts
-
GitHub - jdogresorg/Broadcast-Token-Naming-System: Broadcast Token Naming System (BTNS) specs, docs, and tools
Broadcast Token Naming System (BTNS) specs, docs, and tools - jdogresorg/Broadcast-Token-Naming-System
-
-
v9.61.0 release is out... in the process of updating the xchain and API servers... this update requires a rebuild of addrindexrs data, which can take a few hours.
-
not on XCP named assets, but on BTNS yes
-
XCP named is uppercase english letters only
-
does the dust fixes include the multisiend dust issue that I ran into when I could not force the 1st part of a multisend to have more than 546 sats for the second tx to consume ? .. I am still waiting for my un cpfpable 1.3 sat byte tx to confirm .. maybe at Christmas the mempool will clear
-
I have managed to deserialise a tx and add a output ,.., so I am gonna test adding a cpfpable output to z multisend ..on the end of the 2nd tx
-
No... looks like that issue is still open.
-
Dust Size in P2SH Encoding · Issue #1269 · CounterpartyXCP/counterparty-lib
I am trying to increase the dust amount used in the step 1 of the 2 step p2sh multi send encoding method, so as to have control over how many satoshis are available to be used as the transactions f...
-
will get it into the next release 🙂
-
will be adding custom_outputs param in next release anyway... so will be revisiting the P2SH dust code 🙂
-
-
added the bug i found in BTCpay as an issue. lmk if this is the correct place to post it ❤️
https://github.com/CounterpartyXCP/counterparty-lib/issues/1278Bug for small BTC size order with BTCPAY · Issue #1278 · CounterpartyXCP/counterparty-libLooking to see if this bug mentioned here CounterpartyXCP/cips#96 (comment) can get looked at and fixed to help new users wanting to use small amounts of BTC to be able to succesfully use the BTC/T...
-
Thx.. will get that lowered in the next release
- 18 November 2023 (4 messages)
-
@jdogresorg I remember reading with the past update a circumstance could arise where you are required to make or enter a password and if you mess up your wallet is locked forever. Is this still the case? I’ve been afraid to open my wallet -
Yeah, there was an issue in FREEWALLET 0.9.24 where a wallet could get locked and not unlocked.... but, that issue was only out in the wild for a few days, and 0.9.25 fixed that issue and works fine
-
You should always have backups of your 12-word passphrase and private keys... just in case 🙂
-
Thanks Jdog you the MVP
- 20 November 2023 (14 messages)
-
What's wrong?
-
You tend to have a habit of doing this... "Anyone know whats up with the counterparty servers?... is xchain down?"... rather than asking general questions, perhaps try demonstrating WHY you think there is an issue.... AFAIK there are no issues, all servers are up and operating normally... if that is not he case, perhaps try showing some evidence as to WHY you think it is having problems, etc.
-
Always Mikes fault afaik -
online wallet
-
Those are just status that says "unknown" for CP. For me tx are working correctly. Have you tried?
"up and operating normally", sorry there is no clearer way to say what it says
@jdogresorg I wonder how you do this for a decade lol.. Your the best 🔥 -
Anybody interested to see the visual infographic of Counterparty Tokens/Project/Developments/Forks from 2014 - 2021?
https://time.graphics/line/858561Counterparty Historic NFT Timeline - TimelineAll events are represented on the interactive timeline and can be visualized. You can review all the cause-and-effect relations of timeline
-
it means counterparty and xchain and freewallet are all working normally.... counterwallet is old/outdated and NOT the way most users use counterparty (doesn't support the latest features).... I restarted counterblock, so those srevers should be back up again shortly
-
Idea for a CIP: Now that Counterparty defaults to using op_return and only uses p2sh and multisig when needed could the restriction on needing a user to have first made a transaction revealing their public key be relaxed little?
This would allow users to more easily interact with Counterparty.
This change would allow all op_return based counterparty api functions to be available to new users without them first having to have made a bitcoin transaction.
So the first transaction they make could be a asset send or a dispenser opening or an asset destruction - 21 November 2023 (84 messages)
-
CLONE COUNTERPARTY CODEBASE AND MAKE A NEW PROTOCOL WITH A ASSET NAMES WORKING, CALL IT ALPHAPARTY AND LAUNCH IT ON BSV CHAIN
-
Asking for A assets...
It was my first question in Counterparty Slack in 2016 😉 -
well, maybe not my first question, but it was my first big burning question :)
-
Houston…. You’re aware this is the DEV channel right???… for conversations on development…. If you just have general questions and “Is x working”, please take it to the main CP channel….. let’s try to keep
This channel focused on DEVELOPMENT talk please😃👍🏻 -
I'll pipe down as well, not the place for my odd humor.
-
Sounds reasonable…. Pls create a GitHub discussion for it to log the idea…. Can prolly get in next release👍🏻
-
I enjoyed ur honest yet smartass reply…. Alphaparty😜
-
At one point I was seriously considering an attempt at porting to Algorand and calling it Alphaparty for the lulz... but then Algorand hired a Woke CEO and worked with the Clinton Foundation in India, so I was like "Fuggem" and forgot about it.
-
you might recall my post on that topic couple of years ago, where I was excited to see if Algorand Standard Assets plus their atomic rollback support in their TEAL - transaction execution assembly language - would unlock a range of near EVM like capabilities
-
This is awesome bud, a great graphical representation of all the milestones, well done -
Thank ya! Lots of help from you too
-
Idea for CIP - Relax rules requiring a user to have published a pubkey · CounterpartyXCP/cips · Discussion #125
Now that Counterparty mainly uses OP_RETURN it would make on boarding new users easier if the rules requiring a user to have previously published a pubkey could be relaxed A pub key is only require...
-
What's the logic for restricting how many times a dispenser can be refilled?
If a dispenser is successful and sells out everytime why prevent it from being refilled?
A user can always create a new address and open a dispenser ..so why prevent a refill to a successful dispenser ? -
I don't see refill limit mentioned anywhere in this chat. Is it mentioned in GitHub? -
I see refills were mentioned on git hub but not refill limits
-
it makes no sense to me but perhaps I missing something ?
-
I tried to address a very real concern coming from the perspective of a publisher
-
We put the dispenser limit in to limit the amount of dispenses dispenser could do… to address the hot wallet address dispenser issue that counterparty has… we put a refill limit on so that certain dispensers who wanted to dispense over 1000 could via a refill….. as some community members were saying they wanted dispensers that could go over 1000…. So we provided a method to do over 1000 dispenses via refilling a dispenser up to five times.
I failed to see why a dispenser refill limit is a huge deal … you can close the dispenser at any time… abuse of dispensers are automatically closed at 1000 dispenses.. and users, who want their dispenser to dispense beyond 1000 are able to do so via refill. -
You are in the minority who feels that the hot wallet dispensers are not abuse…. The majority of the community feels that the dispensers are abuse, and are sick and tired of seeing counterpart being beat on….. even the original person who created the hot wallet dispenser has apologized and said he would close it if he could
I’m sorry you do not see a single address spamming counterparty with over 30,000 dispenses as an issue … the majority of the community does -
Refills being limited when new dispensers can be setup seems to make dispenser refill limits pointless
-
it only seems to serve as a punishment mechanisim on successful dispensers
-
Refills on dispensers was added by request of community members who had set up dispensers on Wallet addresses, like Satoshi’s address… where they were upset that the thousand dispense limit would close their dispenser… allowing a refill on that dispenser allows them up to 5000 dispenses
-
by why limit refils ? why not allow unlimited refill?s .. refill is les database bloat than new dispenser on new addresses
-
an address being re used is more compressible than an endless amount of new addresses
-
Because we also added the origin field, which allows the original person who opened a dispense to reopen a dispenser on that address so if we did not a refill limit on then people would be able to refill forever… dispense limit and refill limit sit in the sweet spot where we limit the amount of bloat to the counterpart database allow dispensers to dispense up to 1000 by default up to 5000 via refills
-
Driving to yoga will be back on in a little bit to answer any additional questions…. Please keep in mind that not everyone is always going to agree with code…. But that at some point someone has to do something to address issues….. over 200,000 has been lost via rug Spencer’s in the last year so I’m implementing Jose block closed delay….. we have a problem with dispenser spam and have for six months… so I am implementing dispense limits and refill limits to address this issue…. As always code can be changed and tweaked… but with no changes the issues remain
-
Driving to yoga will be back online to answer any questions in a little while
-
I personally do not agree with the 1000 dispense limit .. it makes CP more expensive to use for successful dispensers .. I understand there was an issue with a dispenser on a exchange address.. but additional logic/cheks on what is considered a 'empty' address can prevent such dispensers being opened
Now everyone everyone must pay more to open dispensers if successfull .. I would be happy to pay a xcp fee for larger dispensers .. but paying miners over n over n over again simply increases the price to use CP and dors not limit dispenses of a token -
xcp is anti spam when it comes to Sweeps so why not dispensers?
-
You are correct additional checks on dispensers before opening them could solve this….. which is why we took a week to redefine what empty was to me no XP or BTC history… yet another change in this update
-
Many in the community see counterparty as a shit coin, and do not use counterparty specifically because it has XP this is a silly viewpoint, but it is clear the community at large does not want more requirement of usage of SCP
-
that's a educational issue.. Burnt bitcoins are not shitcoins like say eth with its premine
-
Agree… but An educational issue never addresssed in 9 years…not an easy issue to solve👍🏻
-
a lie can encircle the globe before the truth can get its pants on
-
XCP is the mechanism used to charge for dividends and sweeps and registrations ... if ppl don't want to use xcp that's fine .. but how do they sweep? I guess they send asset ownerships one at a time ? or do they stand down on their misguided principles and pay the xcp fee?
-
sweeps have even been updated to use xcp in a new way very recently ..so community seems OK with xcp from that perspective 🤔
-
sweeps have always used XCP
-
And almost noone use sweep
-
Sweeps are not a daily use thing like say sends are .. but they are a very useful tool ...
I am planning to build sweeps functionality in to my CP P2SH Multisig wallet as its best way to transfer many assets .. Multisend is lacking at the api level so sweep is better option even tho it means having to use 'a shitcoin' 😁 -
So shitcoining is OK when sweeping and doing dividends coz it's always been that way but no new shitcoining shall be tolerated. Yet we are ok to do more shitcoining when DB bloat is a concern with potential sweep abuse ... but we mustn't add xcp antispam tech when faced with actual dispenser abuse, instead we restrict dispensers even tho the abuse was fixed by redefining 'empty address'
-
XCP has always been an anti-spam mechanism…. Not a pay to use the system token…. XCP has traditionally only been used to prevent spam….. bulk asset registrations… Sweeps where thousands of records can be created in a single transaction, etc.
I agree XCP is NOT a shitcoin … but it is an anti-spam mechanism token originally… and I am of the belief that we should keep it as an anti-spam mechanism….
I think we’re fundamentally talking about a differences of viewpoints of how counterpart should be used …. It sounds like you want people to use XCP to pay for every action in counterparty?…. Or at least that’s the direction it seems we’re going with requiring XCP for more functions.
I personally prefer to only use XP as an anti-spam mechanism …. The exact same way the founders used it.
If the founders wanted XCP to be a pay to use system, I imagine they would’ve put an XCP requirement on sends, orders, broadcasts, and other functionality that users would use daily….. however, they did not do that for a reason. -
I am not pushing for xcp to be used for all actions ..not at all .. I am of the opinion if DB bloat is a problem then xcp anti spam tech is the way to go ..dispenser issues have been addressed by increasing btc fees (dispenser refills are pure btc tax on dispensers) xcp antispam didn't even get a look at
-
To clarify, redefining empty, would not close dispensers, already opened on hot wallet, addresses…. The only way to close those problems dispensers was specifically calling them out with a blacklist which the community did not want or to limit the number of dispenses any single dispenser can make which is what is in the latest release
-
the origin updates allows such dispensers to be closed and the user would have done that I thought they said
-
Closing the dispenser on the hot wallet, addresses only solves the problem on those dispensers…. It does not stop someone from doing something similar and creating a dispenser on an address which will dispense hundreds of thousands of times….. a user closing a single problem dispenser would not stop the problem of a single dispenser dispensing forever…. Hence the dispenser limit of 1000.
I’m sorry you don’t agree with all the updates in this release , however, they were all well thought out discussed with multiple community members, and tested before being implemented.
If this new release introduced a problem, then please come at me with evidence of a problem.
You have mentioned how theoretically it could make dispensers more expensive to use because a user could have to refill up to five times ….
Yet failed to see or mention the fact that adding the origin field allows for things to be done much cheaper…. No longer does a user have to send BTC to a dispenser address and then send BTC and tokens out of that dispenser address to the original address…. Dispenser addresses can be managed remotely from the origin address…. You can open a dispenser on an empty address close the dispenser on an empty address from the origin, and have the dispenser funds credited back to the original address instead of the dispenser address.
This addition alone, makes dispenser management much easier and saves tons of bitcoin that would be wasted, moving tokens between dispenser addresses, and origin addresses (something we see happen many times each day)
I’m sorry that you disagree with dispenser refills .. they can easily be enabled or disabled in the future if they become problematic and the community wants a change…. But considering that all of the dispensers that have ever been created, only a handful of them have ever been refilled, and of those, we have not seen one dispenser refilled five times. -
I very much like the origin dispenser update .. I have had to move btc to close dispensers in the past, being able to manage a dispenser from a remote address is a great solution to a real problem
-
I would have thought creating successful dispensers would be seen as a good thing not a bad thing ... and if too successful then applying some xcp antispam tech ... like I dunno every 100,000 dispenses needs to burn 1 xcp or something .. a price that's reasonable would need to be decided .. this assumes its not possible to open dispensers on exchange addresses which I understand is now the case
-
if no xcp was available to burn after 100,000 dispenses then force close it
-
You can still open a dispenser on any address with no history… so we still have a situation where someone could pre-announce a busy address before it has any history… another person could open up a dispenser on that busy address, and we are right back to where we are now with dispensers opened on high volume addresses, and no ability to stop them without a limit
-
yeah its impossible to know how busy a address will become
-
How would that even work? The dispenser operator is supposed to guess how many dispenses their dispenser will have, and pay some XCP fee, which some community members have determined, is fair before having a dispense??
That seems to make using dispensers much more complex as it requires them to get XCP before they even open up a dispenser.
No solution that someone put forth is going to make everyone happy . The solutions put forth in this release address problems that counterparty has and uses XCP in the way that it traditionally has been used as an anti-spam mechanism
As I mentioned, earlier code can always be tweaked and removed if it proves to be problematic or the community as a whole wants it removed … but counterparty has issues now that need addressed now, which is what this release does. -
Sounds like an interesting proposal… I’d be interested to see it written up and possibly implemented in the future if the community agrees with it
-
escrow amount and price determine how many dispenses are possible
xcp not needed if you plan to dispense well below xcp anti spam limit.. so if dispenser is opened with no xcp balance it can only dispense 100,000 times.. if you want to dispense 500,000 token then 4 xcp will be needed ..1 for each 100,000 dispenses above the initial 100,000 -
yeah and then your not hitting anti spam limits ..one tx and done
-
max dispenses is determined by escrow amount and price
-
That sounds interesting.. I’d be curious to see it written up n know what your XCP requirements are and your dispenser limits are set at… could be a workable solution in the future
-
user could add xcp to allow continued dispensing
-
I just trying to think through how to prevent the spam ..yet allow users to have dispensers that are not limited by using xcp for antispam
will practice at CIP creation with my pubkey idea I opened a discussion on and then look to write a dispenser one -
I hope one day to sell one million unlocked tokens ...I expect I am not alone 😂
-
I would like to hear your opinion on how much xcp should be used for antispam ... i said 1 xcp per 100,000 dispenses to illustrate my point .. perhaps its 1 xcp for 1000 dispenses is the correct amount ?
-
Considering the entire counterparty database is 2.5 million transactions…. I think we’re pretty far off from being able to have millions of dispenser records…. I definitely want to see counterparty scale up to handle more transactions….. but we also got to figure out a way to keep the database small and sane and not explode….. or else the whole tower of cards falls down. 😢
Finding that sweet spot is the constant struggle 😜 -
Well, if we use the same logic that we just implemented and sweeps where it is 0.001 XCP per database hit… a dispense hits the database three times
One hit for the dispense record
One hit to update the dispenser record
One hit for the credit record
3 hits == 0.003 xcp per dispense….
But I’m just spitball numbers right now ….. -
ok 1 million is a lot if we only at 2.5 million so far after all these years .. and thank you for the info re sweeps pricing in xcp and database hits for dispenses
-
'I’m sorry you don’t agree with all the updates in this release , however, they were all well thought out discussed with multiple community members, and tested before being implemented'
May I please have a link to this? Documentation of testing. Discussion with multiple members involved. Did that all happen on GitHub? -
The release has links to all pull requests that make up the release… each pull request is linked to an issue or enhancement and includes testing info in the PR
It’s all linked and available if you look…. Also conversations took place on github, forums, n dev chat room, same as always. -
does this update fix the issue created with modifying callable assets when the initial change to issuance was made? https://github.com/CounterpartyXCP/counterparty-lib/pull/1258Issuance backwards compatibility by pataegrillo · Pull Request #1258 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
Yes… we now use new ids for asset/subasset issuances instead of modifying the old format…. Should be able to parse all issuance types now
-
@pataegrillo should be able to answer the more technical questions if you need more info 👍🏻
-
it looks from the PR that it just accepts the new IDs for issuance txs but doesnt actually revert the unpacking of issuance 20 and 21 types to what it was prior to adding the lock and reset flags
-
i could be missing something tho
-
False
-
-
I don't remember, but I'll check in a few hours -
pls, remind something, you have some tokens with callability properties and you want to create an issuance to change them but you can't because you get the "can't change callability parameters" or something, right?
-
Yes exactly that
-
I can give you Txid
-
-
i think i fixed that, I removed the callability verification in the new version
-
so, in theory you should be able to create an issuance with those assets
-
Ok cool, this PR right? https://github.com/CounterpartyXCP/counterparty-lib/pull/1219Callability verification removal by pataegrillo · Pull Request #1219 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
- 22 November 2023 (1 messages)
-
Thanks for taking the time to explain your claim again
- 26 November 2023 (9 messages)
-
Joined. -
I can't create emblem vault.
I see "Check Fields!" disabled
Anybody have idea? -
-
umm, that doesn't make sense to me, why dm for quote price if its in a dispenser?
-
okay... well I'm interested in a second DJPEPE, but not at 0.25 BTC
-
0.21 would work
-
ok, please let me know when
-
This is the dev channel… for talk about development…. Not basic support questions that ppl can answer in https://t.me/Counterparty_XCPOfficial Counterparty Chat
Website — https://counterparty.io Docs — https://docs.counterparty.io GitHub — https://github.com/CounterpartyXCP/counterparty-core Twitter — @CounterpartyXCP
- 27 November 2023 (48 messages)
-
Basically the stamps community just needs to delay the block activations that were pushed for this is all it boils down to. Give us time to test and validate as we have all been buried in getting the indexer prepped for release.
I believe the push to master is being resolved with a dev branch so no surprises happen until a dev branch is ok’d and tested by all the node runners -
so node runners drive consensus now? heh
-
Isn’t that how btc works
-
I replied to your comment about your desire to run a unnecessary FULL PARSE before you update your servers
-
PROTOCOL MINOR UPDATE: V9.61 · CounterpartyXCP/cips · Discussion #124
Let 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, ...
-
We need a full parse on stamps data not necessarily cp data
-
so... since we only have like 10-15 people running nodes.... I guess that means that what the COMMUNITY wants doesn't matter, just the ppl who run the nodes? Counterparty is not Bitcoin
-
We are in the midst of doing that with the prior version of cp
-
Well then we and xcp.dev fork from xchain. I believe that has been your wish all along
-
got ya.... then a REPARSE on the bootstrap should ensure that the CP data is good... then do a reparse of STAMPS data (if neccessary).... could just compare TXLIST and LEDGER hashes between your 9.60.2 database and 9.61.0 database 🙂
-
I replied to your concerns about a FULL PARSE... hopefully addresses some of your concerns. 🙂 https://github.com/CounterpartyXCP/cips/discussions/124#discussioncomment-7685889PROTOCOL MINOR UPDATE: V9.61 · CounterpartyXCP/cips · Discussion #124
Let 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, ...
-
i was just curious after trying to read through the proposal and comments if there was some main impact that the update was seeking to make as it wasn't clear -
how is this so urgent anyway?
-
LOL... yeah... for whatever reaons you think I want to push SRC-20 and stamps off CP.... no matter how many times I explain that is not the case, and that the issue was spamming... and even OTHER community members explaining it to you, you still see me as the villian
-
So... I'm happy to get out of the way and let the CP community handle pushing forward releases going forward 🙂
-
It isn't urgent.... all the changes have been discussed and pending for a long time.... this is the SAME exact release process we have always followed since the beginning of time (2 week activation after release)..... this whole painting it as a RUSHED release and as forced centralization is nonsense..
-
i dont hink everything has to be black or white, te dev branch actually is a good idea, to have a few nodes running it to verify there is no breakings in any of the projects that shares counterparty protocol
-
agree... using develop branch IS a good idea... which is why I said 3+ weeks ago after this release we would start using develop... DEVELOP and MASTER are now in sync on 9.61.0.... which is what juan and others wanted... to use develop
-
i understand the reparse vs a full reparse however given our workload we did not digest the changes or to get prepared to make them. Doesn't seem like an unreasonable ask. especially if so few in the community are actually running nodes.
-
rushed is a relative term of course. it is rushed for us at this point now that we are putting more attention on the details of the implications of the change which require an upgrade to stay in consensus with xchain
-
Cool... I look forward to watching you guys figure out how to move CP foward... I'm going back to just being a normal community member now with opinions... I'll still run xchain.io and freewallet.io... but i'm done with pushing any changes forward on CP dev for a while.... it is a thankless job.
-
I already made this decision last week, and reached out to a few OG community members that I respect (@hodlencoinfield and @jp_janssen and @shannoncode) and requested that they request github repo access from the founders (as they are the owners of the project and the ONLY ones who have the ability to add devs to the team, and enable github commit access).
-
i don't believe there is anything inherently wrong with the changes. most of us are new to these major changes and process flow so need time to adjust is all. The new stamps indexer will bring at least several new cp nodes online with it so it's a benefit for everyone
-
sounds like a good step to get more devs in there to make collective decisions. I don't see this as contentious or you as the villain fwiw. just a slight change to the process and temporary delay is all as we evolve together and continue growing things.
-
hehe... just a slight changeUnfortunately what is being DEMANDED by Juan is a change to how CP is run, consensus is run (nodes decide consensus now, not users, not community, not devs).... etc... Funny how the new devs are the ones objecting and saying how things SHOULD BE.... and ignoring the advice and knowledge and history of what IS and HAS BEEN.
-
100% support jdog in his decision, but will miss him in the maintainer role, hes probly the only person i know that cares about the long term success of counterparty more than i do
-
i'm not even clear of all the requests made by Juan and don't care to get into all those details. Simply put we run a node which is imperative to stamps and a consensus change like this needs further review. If changes are being made to how it is being run with more devs having access and control on the rollout that seems like a good thing
-
i have no doubt there is lots of passion there, it's very evident.
-
nothing jdog is doing now is any different from how counterparty has been maintained all these years, all the development happened in public there was ample time for people to make suggestions, totally respect having a different opinion on the process and we can def make changes which jdog has also recognized quite publicly
-
maintainer is a thankless job, i am thankful that jdog decided to take that burdon on from the moment the founders stepped away
-
also have you looked at the update? it adds great functionality that we all agree we want
-
Jdog is not the founder? 😅 I'll end up completely lost lol
-
closing dispensers from the origin address
-
perhaps consensus changes get a longer window of review. open to whatever you guys decide. we simply want to maintain consensus with all node operators and grow with things at a suitable pace. once we are done with this release it will be feasible to dive into the CP code in more depth and rewiew upcoming tweaks - considering that is the code base we used for the stamp indexer it's very easy to digest.
Sorry for not being tuned into the proposed changes earlier. Still getting up to speed on things. -
transfer assets without changing asset description which specifically helps stamps
-
what exactly is your concern about running it?
-
Some of them are cool indeed, but reading all PRs is soo complicated. If releases were more atomic, it would make things way easier.
-
yeah i have seen chats on these things and don't have any issues with them in general. it's mostly just a timing thing with everything we are currently working on is all.
-
whcih we could talk about but thats not whats been done historically
-
never was a founder..... never wanted repo access... only got repo access AFTER john died.... same with all the CP properties... only got them handed to be when the founders walked away cuz I was the only one running stuff still..... never was about a power grab... I was always here cuz of my love for CP... but time for the torch to be passed to other devs... I have absolute faith that @hodlencoinfield @jp_janssen and @shannoncode will treat the github repo and commit access with the respect it deserves, and only push forth changes the community wants.... overall this is a good thing for CP..... you wanted more github reviewers and coders, now ya got it 🙂
-
Good to know, I heard things some day and assumed it was true
-
yup... ppl make up history, very few care to ask when it doesn't serve their purposes 😛
-
thanks for sharing. Very good to know the history. Thanks for all the hard work indeed. we'll all keep pushing things forward collectively i'm sure. I think we've all come a long way in holding it together and maintaining growth.
-
- 28 November 2023 (60 messages)
-
@hodlencoinfield since it appears you are one of the peeps in charge now can we please request a deferral of a week to get this tested so we can stay in consensus here. If that’s not feasible or an inappropriate request just lmk for sure. Happy to help define a clear process as we will need to be do the same for our public repo and it will be a good reference of process.
-
Personally I don’t see any reason to not update as scheduled, what stops someone else coming in a week from now and saying they too also haven’t been paying attention and need another week. Do you have any specific concerns about the update itself?
-
Would it hurt to delay a bit? What would stop another would be that it already have been delayed.
A concern to me is the amount of changes in this release. I'm very sure you've done a great job and a lot of features are great and waited by a lot, including me.
But atm, it feels unreachable to read and test everything in the release if you have not already actively worked in the project.
@jdogresorg , big up for staying onboard for that long, some more people are coming.
More people are starting to run CP nodes, I feel this as a good thing.
I understand the drama, Juan has been a bit aggressive and the more talk kept going, the more tension there was.
It looks like it lead to be no concession at all, not even a week or two of delay. -
Heavy is the crown
-
You going to take constructive objections seriously and not slide them?
-
Concerns include the consensus changes completely untested on our end yet. A lack of documented process for minor vs consensus updates. Other concerns in GitHub that have not been addressed, etc.
It’s not a publicly held company here with tight timelines for software release and budgets.
It’s just a simple request amongst friends sharing memes so we can prepare and not fork from xchain is all it boils down to. -
Have you attempted to upgrade or were you under the impression there would be a delay in activation?
-
Im curious why there is no time as the activation block announced a week and a half ago and has been in the works for months
-
I understand process concerns and i believe that’s begun to be addressed and is a priority going forward
-
Should we go through the changes together in here one by one so you can highlight areas of concern?
-
Could just go down the list in the PR
-
Poe's law
-
have not yet attempted upgrade or verification. This just really came up on my radar the other day as to the implications of such a consensus change.
-
realistically a host of work and professional obligations, added in a holiday week, loads of company, screaming babies, compounded with sleepless nights working on the stamps public indexer. Most of this is solely on me ofc, however several other new important devs which are helping and getting familiar with CP and it's processes are also unpreparaed.
-
Is it just the fact that there are consensus changes in general or is there a particular one that concerns you
-
This was simply a personal request amongst friends. if there is too much conention with me do defer then that's fine. We are all here getting familiar with these major releases and learning to work together. Understanding that personal requests are not acceptable is fine.
-
i don't even know yet besides that consensus is changing and we aren't prepared to upgrade as of yet and the clock is ticking quickly.
I guess if it activates on xchain and we don't upgrade. What happens in a week or two weeks after we are able to digest and push the upgrade to all unseen assets and the implications of those transactions being out of line between nodes? -
i guess that's the biggest unknown unknown..
-
You would be out of consensus in that case, and likely would be dealing with user issues as a result, also there would be no replay protection for users
-
It’s also not just xchain that is upgrading, there’s emblem, pepewtf, freewallet, scarce city, etc
-
Haven’t heard any concerns from anyone else
-
Actually that’s not true, Juan is concerned but his comments are process related afaik, there was one concern with issuance backward compatibility but Javier pointed out the PR where that change was
-
ok so we are are forking from xchain which has been what we have been trying to protect for the community as a whole through at least one turbulent time already. Which then comes back to my personal request for a delay while we get new devs that are helping on the indexer and getting familiar with the CP processes up to speed to help test things as well. this includes xcp.ninja (noop), derp, rarestamp, and others that are commited to the future success of CP and stamps. I don't care to be the mouthpiece for this, but it has taken considerable efforts to onboard such resource.
Those other resources don't have the implications tied to assets build on top of the protocol and major infrastructure tied to it. -
I think as time goes on the fact you’re building an indexer on an indexer is going to create more issues for you
-
Just like bitcoin changes and counterparty reacts, as counterparty changes your additional stamp indexer will need to react
-
Correct. Next iterations will be moved to a lower level as we do with src-20 directly on bitcoin to avoid such problems. In the meantime we are relying on collaboration and understanding.
-
So my understanding is this, correct if I’m wrong, you guys weren’t paying attention to counterparty development so this update took you by surprise, you don’t actually have concerns about the updates themselves but just the fact that there are updates
-
Why don’t we take some time to go through the update?
-
Do you have time right now?
-
Basically. All the basics of the upgrades sound great. Fully support them. Simply concerned about the high potential for a fork and wishing to avoid it. Now that we are more aware and getting familiar with the release updates I wouldn't anticipate this issue in the future.
-
not much time to get into it super details. but some overview of the consensus changing aspects and how it will impact potential indexing and nodes seeing these new transaction types is certainly helpful until I can rtfm in detail.
I'd feel more comfortable with it as i get a node in plact to test an upgrade, run our index validate, and verify all of the other direct to cp database operations we have aren't impacted and then all good on my end. Just scrambling with some new hardware, personal, work, and stamps indexer moving into production and public release planned for this week is all.
I trust the process flow will be improved for the next releases. I have not been comfortable pulling random updates from main without a release version. -
Are you in the process of doing this?
-
hoping to clone an image of our production instance today and setup all the requirements today. things are just in mass disarray with the pending production migration on our end so I have the current and future code to validate. Major db cluster migrations, big api changes for v2. the list is massive. Just bad timing is all. Once I get everything in place confirming things are ok shouldn't take more than a few days.
-
it is being taken seriously. just not totally comfortable moving forward blindly.
-
Might be prudent to delay your new release, there shouldn’t be anything in this update that breaks stamps, it’s all backward compatible in fact it fixes an issue where the current version is not backward compatible with callable assets
-
that is certainly being delayed there is just a lot of things that need to happen to prepare regardless. I'm optimistic it will be fine. It's simply a reqeust for deferral so I don't need to rush and move into unknown territory without testing. It's much simpler to just stay on the current release and not stress if the request cannot or will not be accomodated.
-
truthfully all the back and forth spending time explaining is frustrating for everyone i'm sure. I'd rather be focused on the matters at hand.
It's just a "hey bro, can we get a little more time to suss out this code before going live as I'm not prepared at all" -
It’s just that we’ve announced an activation block and changing that is not without issue for everyone else that’s planning to activate, so we run into a situation where someone setup a node to activate and what happens if they’re not prepared to revert back to the current version
-
I hope you can appreciate that your ask isn’t as simple as “just push it a couple days”
-
Obviously if there is an issue with the update itself that needs to be addressed then we should do that
-
ok that's a very undertsandable response and i can live with that if key stakeholders don't have the time to revert of make delays. I'm not familiar with all the other pieces in play. That's really the feedback needed so we can decide how to proceed. I'd rather not find out issues after the fact is all.
-
I really don’t think you’re going to run into any issues, jdog removed all the controversial changes (like separate data store and taproot address) for this update
-
The great part about indexers (counterparty included) is that if there are bugs or issues that crop up then we simply get stuck at whatever the block height is until the issue is resolved and then just catch back up to the current block height
-
We have had excellent uptime with jdog and Javier as custodians and jdog has no reason to introduce any issues because they’d directly affect xchain and freewallet and make his life more difficult
-
All the details are laid out nicely in the PR
-
With links and all
-
-
None
-
Pinned for reference
-
I'll trust you're right. It's just not my modus operandi to push untested or rushed changes. Thanks for the understanding and chatting through it with me. I'll take it as it is with the planned upgrade. Will also be planning to get a full dev environment up so we can test updates to the dev branch in the future as well. Looking forward to getting more involved much earlier in the process.
-
being that we are only a couple days away. are nodes actively upgrading production now I assume?
-
yep, i think it should hit the activation block on friday
-
for the stamps side there are two primary and 8 additinal devs involved with testing. Besides me there is only one other dev maintaining production CP nodes if the question was for me.
-
yep we'll be moving to develop branch for changes going forward and will work to keep the process as transparent as possible so people dont get caught off guard
-
Excited to see more devs stepping into lead roles and working together to move Counterparty forward 🫡 - 30 November 2023 (1 messages)
-
Joined.
Official Counterparty Dev Chat
Public archive of Telegram messages.
- 01 Nov 2023 (101)
- 02 Nov 2023 (48)
- 03 Nov 2023 (2)
- 04 Nov 2023 (1)
- 05 Nov 2023 (1)
- 06 Nov 2023 (1)
- 07 Nov 2023 (15)
- 08 Nov 2023 (2)
- 10 Nov 2023 (7)
- 13 Nov 2023 (7)
- 15 Nov 2023 (18)
- 16 Nov 2023 (15)
- 17 Nov 2023 (27)
- 18 Nov 2023 (4)
- 20 Nov 2023 (14)
- 21 Nov 2023 (84)
- 22 Nov 2023 (1)
- 26 Nov 2023 (9)
- 27 Nov 2023 (48)
- 28 Nov 2023 (60)
- 30 Nov 2023 (1)