Imo we need to put forth a solution to address rugspencers. We continue to see ppl getting taken for funds via rugging dispensers…. So I think we need to take some action rather than sit by n let the scamming continue because we can’t agree on a perfect solution (there is no perfect solution).
I think we should move forward with Joe’s idea to delay dispenser closes by 5 blocks to give any pending dispenses a chance to settle.
https://forums.counterparty.io/t/cip21-dispensers/5488/14
- 01 October 2023 (39 messages)
-
-
Unless there are some serious objections, I think we should delay dispenser closing by 5 blocks in the next release
-
5 blocks look short, except by putting very high fees it's kind of hard to get a tx confirmed that quick. -
We should close this issue then https://github.com/jdogresorg/freewallet-desktop/discussions/156
I guess you must be true, everyone knows how to validate a tx in 5 blocksShow sat/vB and allow user to set fee rate · jdogresorg/freewallet-desktop · Discussion #156People often want to set the fee rate in sat/vB to know how quickly their transaction would confirm and how expensive it is relative to other transactions (regardless of # UTXOs used). The fee rate...
-
Freewallet is not a Counterparty project, and as I mentioned yesterday I plan to redo fee estimation in freewallet in the next release or two.
This is a chat room for discussions about changes to the CP protocol…. Discussions on freewallet updates can take place in the freewallet channel at https://t.me/freewallet_ioFreewallet.io ChatThis is a channel to discuss FreeWallet and ask questions and let the community answer
-
We have a 10 block delay for btcpay txs I think -
I could be wrong I haven’t checked that number in a while
-
I'm aware, thx for the effort 💪
-
20 blocks
-
It was just an illustration of why 5 blocks look short to me
-
20 blocks from order match to btcpay
-
I agree, maybe we change them both to 10 or something
-
Feels like they should be in line since the effect is the same
-
But I’m not too worried about it if we just roll with 5 block delay on dispensers for now
-
It’s better than what we’ve got
-
So closing would require 5 blocks regardless of pending txn or only if there’s pending txn? If there’s variance between mempools, how is that really established? -
No just 5 blocks
-
Makes sense
-
It’s an easy way to drastically reduce a scam method
-
Everyone should be paying a next block fee for dispensers anyway
-
Greatly appreciate ur feedback on GitHub n ur code suggestion.👍🏻 The only issue is I don’t make call to cp api until user confirms tx, so no way to display sats/byte until I know actual size of tx….. I’d need to redo the wallet logic to do pre-flight checks to CP api to integrate ur suggestion…. So imo better to focus on better overall fee estimation n base fee on actual tx size than try to do a quick hack to display sats/byte.
Def will get better fee management in freewallet soon…. Tryna close up all the main cp issues n streamline freewallet before end of 2023👍🏻 -
Well this seems more like it would reduce innocent mistakes. Closing a dispenser without knowing. A malicious seller could still just front run
-
Can still front run by activating the dispenser via dispense
-
Why would you have to win by 5 blocks? You just need to outcompete the buyer to buy it yourself
-
That’s more expensive tho
-
Yes, malicious seller could still buy from their own dispenser from a different address n pay way high fee…. But at least makes it a bit more difficult to scam, and requires scammer to have more funds up front to scam (gotta buy out their dispenser at the price they are selling at)
-
DM to avoid dev talk pollution
-
Ok, I'll work on it on monday
-
Javier will have 5-block dispenser close delay PR ready on Monday n I’ll test this week along with a bunch of other fixes
-
Btw, for dispensers, I don't know a lot with P2SH but high level read makes me think it can be a solution. Am I delusional?
-
Delayed closing will solve nothing, rather open up new problems.
Im heading to bed now so cannot discuss more. Will write my reasoning on github tomorrow. - 02 October 2023 (34 messages)
-
Delayed Dispenser Closing · CounterpartyXCP/cips · Discussion #120
It was suggested on Telegram that closing of dispensers should be delayed by five blocks. This to prevent an attack vector ("rugspenser") where seller detects incoming dispense and immedi...
-
I wonder, what happens if a seller closes a dispenser then sends all its assets to another addy?
Its more complicated as it requires 2 txs but still. -
So your suggestion is the same as a year ago…. Change dispensers to a reservation system, requiring two txs…. Which defeats the whole point of dispensers…. Being able to buy in a single normal btc tx…. Not multiple payments.
Imo we have sat in this issue for over 2 years worth ppl saying “we should do X”… and x being a substantial change…. So we sit and discuss more…. And more people get scammed…. And another year passes because we can’t agree on a decision.
Hey, five block delay does not solve all the problems. What is a step in the right direction, is a simple change, is easy to understand for all users, and makes it a bit more costly for scammers to scam.
Five block delay may not be your perfect solution … but it is a solution we can integrate now to address this problem. We can add additional features in the future if this continues to be a major issue.
However , continuing to ignore this issue and let people get scammed out of tens of thousands of dollars each month is unacceptable, does not reflect well on the counter party platform, and needs to be addressed now. -
The proposal is an option. But P2SH wouldn't be a way? I've only read high level description but it looks to a solution where seller would have to confirm a buy to get its money.
-
Dispensers were created by John n myself to address the issue of using btc on CP and being able to pay in a single normal btc tx…. Any option which forces multiple transactions is a step backwards in my opinion…. Dispenser should always work by default with a single BTC payment… and yes, we can absolutely add a reservation system in the future, which requires two transactions for users who want to use that feature…. But dispensers should always remain single BTC payment to trigger as a default.
Just my $0.02 -
Real world dispensers (vending machines) dispense candy bars and soda which have a nominal cost so even if you get “scammed” because the machine malfunctions you’re only out a dollar or two. No one sells cars or equally valuable items through vending machines for a reason.
Not saying a price ceiling should be instituted but I think some re-enforcement of what “dispensers” are meant to do could be helpful. Maybe it’s language or UI. -
reservation is a nice idea for high value dispensers but doesnt really work for low value ones plus there is nothing to stop a scammer reserving their own dispenser using a higher value fee after a legit buyer submits a reservation tx, sure they will only be able to scam the reservation amount and not the whole amount, but it is kinda the same as a scammer buying from themselves even if a delay is added .. its not possible to prevent front running when the mining fee being paid is public information -
Reservation amount would be dust, logically lower than fees scammer would pay.
-
If reservation cost is just dust then it becomes possible to render other peoples dispensers to not function for next to nothing
-
For higher risk you should just use btcpay
-
Every 10 blocks, what an effort for no profit. idk, yes it can be an issue depending of dust size but better than high value btc send scam.
-
Dispensers are the “easy” option, they should never be harder to use than btcpay
-
Dispensers are a trade off, they always have been
-
Was answering to malicious dispensers "lock" issue
-
Having a delayed close just helps eliminate one vector that has been used for scamming
-
Gotcha, the thing is this is a simple incremental change that makes it more expensive for people to rug dispensers, we can discuss alternative ways to “fix” dispensers but that shouldn’t hold up trying to solve a current issue
-
You’re ignoring that the liquidity requirements of this attack is increased by adding the delay
-
Right now it’s a Tx fee to rug any value dispense
-
With a delay the requirement increases with the cost of the dispense
-
Also you’re not considering the number of assets in the dispenser, you would need to purchase the entire balance of the dispenser to close it
-
As opposed to a single low fee dispenser close Tx
-
If those are your own balance, wouldn't final cost exactly the same?
-
It’s a liquidity requirement
-
I would suggest any devs in here that want to “fix” dispensers just work on a better UI for btcpay, it “solves” the problem by matching the order first
-
Im writing up a CIP. Aiming to get it ready today.
-
We all know dispensers are risky, it’s a trade off to making them easy to use
-
I think that’s good but it shouldn’t hold back a fix that we can implement now to help alleviate the issue
-
I added an idea in the Github about having a "Reserved Dispenser" option to solve the questions a buyer usually has when hearing a seller offer an OTC trade... and that is the question of "how do I know someone won't buy this before I do?"
https://github.com/CounterpartyXCP/cips/discussions/120#discussioncomment-7166131Delayed Dispenser Closing · CounterpartyXCP/cips · Discussion #120It was suggested on Telegram that closing of dispensers should be delayed by five blocks. This to prevent an attack vector ("rugspenser") where seller detects incoming dispense and immedi...
-
CIP draft up.
https://github.com/CounterpartyXCP/cips/discussions/121CIP - Dispenser Reservation · CounterpartyXCP/cips · Discussion #121CIP 32 Abstract Reserve a dispenser for 10 blocks by sending a tiny amount of BTC dust to it. This is optional. Dispensers can be used without reservation as before. Backwards compatible. No change...
-
As the CIP editor i don't want to approve my own draft. If it looks good, please reply in the thread whether you approve or what you think needs change.
By cip rules you can disagree with it, yet that won't disqualify it. See cip01 for reference. -
Multiple transactions is optional. For sellers and buyers happy to pay all in one tx, nothing changes.
-
I def am open to the idea of a reservation system... overall I think it is an improvement... tho think there needs to be a bit more discussion to flush out the implementation ( what % of BTC to send, how many blocks to 'reserve' the tokens for, etc), which will require some additional time...
-
Fixed value chosen between 5k-30k sats lgtm.
As it will be only for highly priced dispensers, putting it in % wouldn't solve front run scammers if value is too high.
Too low value may open dispensers "obstruction" behavior, or not engaged enough buyers.
As a scammer would have to spend between 30 and 100/vB depending on current fees, frontrun would cost 4200-14000 sats.
Hence fixed with 5k-30k, a scammer wouldn't bother stealing it.
Also easy to code. -
That's good reasoning. I have not set a minimum (effectively the dust minimum of 546 sat) in the cip but open to changing it.
- 03 October 2023 (1 messages)
-
If you 'reserve' a dispenser with a partial payment, as described in JPs CIP you are in effect creating a delayed close situation on said dispenser, as you would assume a dispenser can no't be closed with a reserve payment in play so a partial / reservation payment necessitates delayed close
- 04 October 2023 (36 messages)
-
FYI... working on dynamic XCP fee on sweeps... moving from fixed 0.5 XCP fee per sweep to a dynamic XCP fee based on number of balances and issuances swept.... moving to a model where XCP fee is based on number of hits to database. https://github.com/CounterpartyXCP/counterparty-lib/issues/1220#issuecomment-1747037727Sweeps - dynamic XCP fee · Issue #1220 · CounterpartyXCP/counterparty-lib
Currently sweeps are hardcoded at 0.5 XCP per sweep. https://github.com/CounterpartyXCP/counterparty-lib/blob/master/counterpartylib/lib/messages/sweep.py#L17-L18 We should change the formula used ...
-
Transfer requires you to input the description so for a stamp it would require re-stamping
-
Most of the minting services do it all in the same transaction to avoid the restamping penalty
-
Does it?
-
Yes
-
I believe it also applies to increasing supply
-
No
-
It’s because that’s how counterparty works
-
=> https://xchain.io/tx/09ce3f8f9a17bd9e32c27723eabea1daf77a32e5c9bf44849e8dd8b24456131d does it mean this tx is not working?
-
-
No description
-
Asset description deleted when `null` · Issue #1224 · CounterpartyXCP/counterparty-lib
Joe Looney and a couple other users have reported that any issuances where the asset description is set to null results in the asset description being overwritten. This is undesirable behavior, as ...
-
This wil be fixed in upcoming 9.60.3 release... so ppl can transfer stamps and just set "description" to null... and NOT have the description updated/touched... 🙂
-
ie.. avoid the re-encoding cost 🙂
-
Hmmm… that actually has me thinking…. Stamps ignore description changes so transferring ownership with a blank description should be okay?
-
That's what I meant as he was linking a stamp
-
Depend where you want to see your asset, if its only in stamp ecosystem you don't need the description.
If it's in counterparty/xchain, or you need to resend the description, or wait for FreeWallet update. -
I think some users might be annoyed that the description field is blank but it doesn’t actually violate the protocol. It’s just how xchain presents an appended description.
-
It’s just how Counterparty-lib interprets what the current description is
-
Not xchain, Counterparty-lib
-
All description updates are present on xchain but the very latest is “surfaced” … is this not a design choice?
-
Let's say both 😅
-
Not saying this is wrong btw
-
At least your stamps will still display in wallet.stamped.ninja even with empty transfer issuance
-
But imo you should wait for jdog's update to be CP compatible
-
In the early days people were transferring ownership before the output bug was fixed so each output had 10x the amount of sats. VERY EXPENSIVE.
-
👋💸
-
Description is a field provided by Counterparty api when querying assets
-
Xchain is showing the same description Counterparty api shows as the “current” description
- 06 October 2023 (1 messages)
-
For ASS (assetic.io) I wanted people to transfer ownership to a burn address as a means to actually lock the description field - massive ballache though as of course people lose their descriptions when doing this transfer, so now I wrap that up in the minting process as an option, and now officially the ASS parser works by reading all the description updates and logging the last valid one as it’s active state - this is way too hard to describe to avg user people so effectively had to cut the ‘send ownership’ part out if they chose to not do that at the mint stage. - 10 October 2023 (10 messages)
-
Is v2.0.0 JSON schema the format we should use? -
(For Enhanced Asset Information)
-
I believe the spec your looking for is CIP25 - Enhanced Asset Information Spec
https://github.com/CounterpartyXCP/cips/blob/master/cip-0025.md
Here is alink to an asset CIPXXV which is using the CIP25 JSON example.... demonstrates how the JSON can be setup and what fields the JSON data render to on the xchain frontend 🙂
https://xchain.io/asset/CIPXXVcips/cip-0025.md at master · CounterpartyXCP/cipsCounterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Thank you 😊🙏
-
-
@hodlencoinfield @jdogresorg someone? 🙏
-
- 12 October 2023 (1 messages)
- 13 October 2023 (4 messages)
-
I urge community members to weigh in on the pros and cons of batch-dispensers.
https://github.com/CounterpartyXCP/counterparty-lib/issues/1148Just 1st dispenser dispenses when batch-sending sats to multiple dispensers · Issue #1148 · CounterpartyXCP/counterparty-libThis is the transaction (generated with a simple blue wallet) https://blockstream.info/tx/11eb2b730e2e383a657c51d7b04bd55271d1e86ac9a2c74d3e3f6c78e88e23ff where correct exact sats were sent to 5 di...
-
-
You have been knighted as "Spammer Yeeter"... enjoy your new yeet powers
- 14 October 2023 (10 messages)
-
Mobile wallet has been down for ages… just me? -
Server errors
-
What mobile wallet? Freewallet mobile?
-
Yessir… on iPad
-
pls try again... seems public.coindaddy.io was having some issues (its on a 5+ year old server... so its slowish n outdated).... will be migrating coindaddy.io to a new server this month .... anyway... I just restarted public.coindaddy.io... so pls try again 🙂
-
Will do thanks
-
Seems to have worked, thanks
-
-
-
One question it says I sent .15. I ony send .0119?
- 15 October 2023 (2 messages)
-
Look at the actual tx for amounts…. The wallet tries to display BTC amount but always look at the tx to confirm amounts…. Prolly just summing the amount wrong in history… I believe I used external api to get balance n the api just summed up the btc amount transferred (including change)…. Drilling into actual tx will reveal the true amount sent/spent
-
Freewallet.io Chat
This is a channel to discuss FreeWallet and ask questions and let the community answer
- 16 October 2023 (1 messages)
-
Thanks
- 23 October 2023 (22 messages)
-
Hey, I have an issue with CP create_issuance route.
It allowed to create, https://xchain.io/asset/A300300300300300300 then obviously ended as an invalid issuance.
For recent asset id, I do have the correct error
Error composing issuance transaction via API: ['issued by another address', 'locked asset and non‐zero quantity']
Is that a known issue? -
A300300.. looks familiar. I might have issued it years ago. Should be listed on Coindaddy.
-
Yaya, the issue is that new issuance is logically invalid https://xchain.io/tx/2525269 but CP api accepted the request and created the TX
-
That’s typical. Need to check for existence before issuance. Ran into that before. Invalid issuances show up in the cp db so they could potentially be useful as spam lol -
Invalid issuances - even more useless than 0 issuance valid assets lol spamming ninjas!
-
Invalid issuances only show up in get_messages and none of the other API calls
-
Which is where we look for stamps btw
-
Imo we probly should purge invalid messages every X blocks or something
-
I do wonder if invalid messages are taken into account when calculating the message hash
-
Fixed a similar issue in this upcoming release… with cp api generating issuance txs which are bound to fail…. https://github.com/CounterpartyXCP/counterparty-lib/pull/1260- Fixed numeric asset leading zero issuances not throwing an error when token exists by pataegrillo · Pull Request #1260 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
Early on, Stamps were done exclusively on Counterwallet which doesn’t do the check and a number of stamps were created invalid in this way.
Example: https://xcp.ninja/asset/A800800800800800800XCP Ninja, the counterparty reference.Explore a wide range of Counterparty assets through a powerful search engine. Tools such as minting, directories and more.
-
Yes… hash is based off all data in messages table, which include all statuses not just valid
-
Interesting, is the ledger hash only made up of valid data?
-
i believe ledger hash is calculated based off all the tables populated by messages... messages hash is based off all data in messages table... txlist is based off hashing all the data in transactions table..... could be wrong tho, @pataegrillo would be able to say better
-
side-note: in order to redefine "EMPTY" as meaning no BTC history, we have had to update addrindexrs to track the block_index associated with each tx (so we can easily/quickly check for the first tx for an adddress given a block index).... since we had to update addrindexrs to track this block_index data anyway.... addrindexrs now contains a bunch more data that we used to have to get from bitcoind.... so, TLDR, full parses and reparses should be MUCH faster now that we are able to benefit from using addrindexrs and data which is already indexed...... still working on a PR and testing, so still a week or two out... but, 9.60.3 should also parse a bit faster (already parsing 2 mins faster over 1000 blocks... but expect to see much faster parsing after testing)
-
Ya, seen the error, we'll update the parser to filter out not valid issuances.
-
yes, in fact, the ledger hash is calculated using the credits, debits and messages (the data on every detected tx) -
FYI... tx fees are pretty low... might be worthwhile to sweep old utxos... I did some tests over the past few days to gather up about 29,000 outputs (1000 sats each).... 500 inputs, 1 output, 1.6 sats/byte .... I did about 40 of these txs and all confirmed within 48 hours.... https://blockstream.info/tx/33de2dfc2b6e522100d5153b1839876ea11f14be200e6011a1616b3ba6f38c75Blockstream Block Explorer
Blockstream Explorer is an open source block explorer providing detailed blockchain data across Bitcoin, Testnet, and Liquid. Supports Tor and tracking-free.
-
Only devs can do that lol. Electrum maybe? But yes 100% saving money if you have over 50 utxo
-
sparrow makes it pretty easy to consolidate utxos
-
Naww… too many utxos for electrum… I had to do it n bitcoin core.. wasn’t that tough…. All point n click
-
Sadly this addy was legacy, would save a lot with segwit, I've seen you made the switch in latest FW release
- 24 October 2023 (1 messages)
- 26 October 2023 (9 messages)
-
Hello Dawn_WMA... this is a dev channel, not a general discussion group.
What I can tell you for free though, nobody's buying DOLLARCASH. -
What even is that? A backed-stablecoin on Counterparty or just a scam?
-
if it looks like a duck...
-
It can be a goose https://stamped.ninja/goosegeneratorGoose Stamp Minting Tool
Mint your own goose stamp with optimised file size. From https://goosegenerator.com by Dmitri Cherniak
-
Someone made it ages ago, did a bit of wash trading on it to give it a superficial appearance of value and left some dispensers up.
- 31 October 2023 (2 messages)
-
If I do a multisend using the CP API what is the derivation path for the p2sh address that is the output in the pre tx that is then spent in the 2nd tx ?
I have the pretx and i feed that back to CPAPI to generate the second tx .. so igave unsigned hex for second tx , and I need the private key to sign it .. so how do I derive it ? -
the signature is the message data
