https://forums.counterparty.io/t/sweep-fee-asset-description-length-limit/6482
Suggested new sweep fee and asset description length limit.
Purpose is to prevent possible spam attack.
- 02 February 2023 (2 messages)
-
Sweep Fee & Asset Description Length LimitThe fee for sweeping is 0.5 XCP regardless of the amount of assets swept. Sweeping an address containing thousands of assets cost the same as an address with only one. For each asset ownership that is swept, one new row is added to the issuances table. The fixed fee of 0.5 XCP is a security risk. A spam attack could flood the DB cheaply. Changing the fee to be proportional to the number of assets swept can limit this risk. I suggest a fee of 0.001 XCP per asset ownership (about $0.01 at $10 XC...
-
LinkI just created a blockchain centipede... Counterparty-lib consensus code v9.60.1 has been inscribed in bitcoin block 774783 https://t.co/Ktw9t5uhyM https://t.co/0fKRJ5ps8B
- 03 February 2023 (18 messages)
-
My reply to the dispenser discussion
https://forums.counterparty.io/t/cip21-dispensers/5488/15 -
The random dispense would be 🔥. It would create a lot of activity. -
One million pepecash n one rarepepe in a dispenser…. 0.001 btc to get a random dispense… interesting… kinda like it👍🏻 -
This would be scary
-
On average you’d be getting 500 BTC with that example, but there’s a one in a million chance to lose a rarepepe for 0.001 -
randomness on the blockchain is an extremely hard problem to solve
-
Sort of random close enough 😂
-
miners can game the blockhash by entering data into the coinbase tx
-
obvi it would need to be high enough value to be worth it
-
Only way is by withholding a valid block, right? And lose a block reward.
-
no, they get like 250bytes to put whatever data they want in the coinbase of the block
-
thats where luke-jr used to put bible verses
-
and that data affects the resulting block hash
-
Hmmm… so they could mine the dispenser transaction and manipulate the hash in a way to get the desired “random” outcome
-
But this asdigned before the work. The block hash that begins with 000000.. is random
-
oh i see what you're saying the value they have to find to mine a valid block
-
be curious to see how exactly you imagine that working
-
Will write a draft next week.
- 04 February 2023 (16 messages)
-
was thinking of creating a comparison table to clear some preconceived ideas around CP (this is a draft of a draft xD) -
If you have other ideas to add or things to correct please do 🐸
-
Nah, it was worked on, then Ethereum shit the bed with theirs and had to roll back the chain. It’s been shelved, but it’s been getting looked at again from my understanding.
-
I would make RSK, Stacks, and Liquid just a footnote.
I’d also consider taking out the no and nots in the left column to avoid double negatives when the answer is no -
No, it’s basically one big smart contract
-
I just joined here to start learning more for myself to contribute. I believe python is the primary language, but others are used for various things
-
I’ll defer to one of the experts in the room
- 05 February 2023 (91 messages)
-
There is no EVM on cp…. Right now all the features are hardcoded… you can create tokens, send them back and forth, setup dispensers (vending machines) to sell tokens for btc, use the DEX to buy/sell tokens… xchain.io will give ya an idea of the features
-
There is some work being discussed on a non/Turing complete vm on CP or a fork, but nothing concrete yet
-
No, user a is the only one who can refill or close the dispenser
-
Docs.counterparty.io
-
Yes download freewallet-desktop from freewallet.io n create a wallet… you can then switch to testnet to do txs on testnet
-
You can view testnet transactions at testnet.xchain.io
-
Yes
-
Just an explorer
-
Not saying it is best… just a lot can be accomplished without turing completeness https://forums.counterparty.io/t/proof-of-concept-vm-development/3031Proof-of-concept VM Development
So i’ve recently started to develop a minimal pure python Virtual Machine tailored specifically for counterparty. I’m starting this thread to keep note of development and design decisions, and also to get input from the community regarding what should the VM do. FAQ Why not use EVM? EVM was designed with ethereum blocktimes and specifics in mind. CP has already a lot of groundwork regarding tokens, bets and a lot of useful functions that don’t need to be recoded in a smart contract. Isn’t...
-
-
jdog muted a member
-
who was scammed
-
mark my words now
-
that you will regret doing this
-
i promise you
-
and by the way
-
Jeezus... just cant escape the drama.... for the record, nothing was delete from chat, and our entire interaction is logged for the entire chat to see
-
i have donated a lot money
-
for you to work full time
-
you are something something
-
mark my words dude
-
as i said. i promise you
-
That is great, that does not allow you to come into the chat room and scream and creat lots of drama and then stop your feet demanding i do enforcement... and when I tell you to chill out, you freak out even more.
-
I am sorry that you feel me requesting you to take a timeout and stop screaming your head off in channels is something taht your taking personally and now threatening me that I will regret. Sad state of affaris
-
you telling the person who was scammed to chill out and kept the scammer operate
-
again.. last time.. I AM NOT THE INTERNET POLICE
-
dont try to make me
-
you were muted cuz you were freaking out
-
then hire the mod
-
its not my troubles you dont have time
-
simple as that.... and have been name calling and freaking out for days... I let it got on long enoug
-
you was donated the money
-
use them for good
-
or dont ask fucking donations
-
period.
-
ok... muting you here as well... this is ridiculous man... talk about taking things personally... grow up.
-
you did absolute nothing
-
ever
-
I have a life, I am not in chat 24/7, I was out spending the day with my son today, and yesterday I was working on code... I am sorry that I am not living my life according to your rules
-
-
muted him for a week just like in CP dev
-
I did my best to provide a pathway to resolution, but that didn't work out I guess -
Yeah I know... I saw people trying to descalate, which is why I figured the community had it handled.... come back from a nice day with my son to some @jdogresorg in the main channel demanding I do X and Y... I say chill out... he says dont threaten him, he donated funds, I should spend my time doing X Y Z... frigging ridiculous
-
Your all good man... I am happy to answer questions, and not bothered by your questions at all 🙂
-
Not at this point, its been an idea for a long time... Javier and I plan to spend some time in the next month or two looking closer at the EVM and its functionality and working on how we can integrate 99% of the same functionality into a non-turing complete VM.... ideally will use something simple to write smart contracts like javascript and then compile to bytecode.... Javier and I have been pretty busy the last couple months with Dogeparty and XChain updates, so we haven't really had much free time to think it all the way through.... but, we plan to once we get some stuff cleared off our plate (xchain updates, dogeparty release, freewallet hardware wallet support / new release, dogewallet release)... so, prolly a month or two away from looking into it deeper.
-
It is def something Javier and I want to work on this year... tho I think it will probably get integrated into Dogeparty first.... seems like a better testing ground before putting it on CP (if CP community wants it)
-
nope... Dogeparty is current fork of CP with some tweaks to write to different blockchain, block time adjustments, etc... but yep, easy to port between the two
-
Time is the only resource we never get back.... I feel ya.
-
wow! thats a brutal schedule
-
Is there a way using like a csv or something to bulk upload meta data to assets? I’ve got 100+ unique I need to update with images, descriptions, etc. -
Nope cause each one needs it’s own Tx
-
Like metamask?
-
No
-
Word, you can use xchain.io api to get information related to addresses and assets
-
Pretty sure it’s same as bitcoin, 80 bytes
-
There are ways to store more info, like p2sh encoding
-
Ruined doge?
-
It’s always had a size limit
-
No
-
At least ever since it’s been a standard Tx type it’s either been 40 or 80 bytes
-
Prior to that it wouldn’t have been relayed
-
What is this quote
- 06 February 2023 (44 messages)
-
Is this Craig related?
-
Ahhh yes prior to it being a standard Tx
-
So in practice only a miner could do it
-
And in practice a miner can fill a whole block with zero fee txs sent to themselves and out in whatever data they want
-
Counterparty stores message data in Tx in a variety of ways depending on the amount
-
Op return is the most common
-
Counterparty lib then parses every bitcoin block looking for messages
-
The collected messages are then parsed and the counterparty db updated accordingly
-
Check out counterparty-lib and go to the messages folder
-
That’s the meat of the protocol
-
It’s actually pretty simple
-
Look at the messages folder in counterparty lib as a “smart contact” and each message type is a function
-
Yes you’d need new message types for a VM
-
But remember that a VM isn’t just a technical challenge it’s a social challenge because you’d need to convince counterparty users that it should be part of te protocol
-
It was already implemented once and abandoned
-
You can only go forward not backward with a public network like this
-
So you get stuck with the primitives you have and need to work around them
-
Bugs are imminent regardless
-
Personally I wouldn’t spend time on a vm because the likelihood of backlash is strong and we really don’t have the development resources to manage it over time as more complex bugs pop up, it’s not predictable
-
But don’t let that stop you 😝
- 10 February 2023 (20 messages)
-
Anyone else seeing this in their node logs?
-
Yeah…. I believe that is just the mempool parsing txs every few seconds…. Once the tx is mined n goes into a block, then it leaves the mempool n those errors should cease
-
its not a big deal... the tx is just living in the mempool.... its just CP parsing the mempool every few seconds, which is entirely normal.... not sure how this would lead to timeouts.... this is simply a tx in the mempool which is indicating that when the tx is mined, it will fail in CP due to X reason.
-
A while ago we tweaked the way that the CP mempool worked.... cuz under heavy load (50k-100k+ mempool txs ) CP was wasting a bunch of time parsing and re-parsing the mempool (each loop, it deletes all data from the mempool table in CP database, then re-builds the table from the txs it detects from parsing the btc mempool)..... so, we tweaked the code so that under heavier loads, we slow down how often we parse the mempool, to prevent exactly that, overloading the server
-
years
-
not seeing that on my fednode..... to me it looks like your looking at old logs from years ago
-
counterparty_1 | [2023-02-10 16:18:45][INFO] Dispense: 1 PEPEGENHEIM from 1PVAjcqTFLsm8ugU79seo2ouTVEcUk19rs to 1J8aLankHbmAHojseGRmWRZoTZKiNVi5GQ (6b060673a5c5cfcd154b3664b30e8ee7f7b6c71ab3eb28104f6545aca1fe1db9)
counterparty_1 | [2023-02-10 16:18:45][INFO] Send: 1 PEPOP from 1FZF4hGuyirVZ81YDuZZHVGBM7mxUBtXU7 to 1FZzA4kPgwvN3cCTEntiPgm2Jwq4U4Zrgt (1b84f379eb8c3566491ac7e87cace0090383065aaf029f038d67ca987bc461a4) [valid]
counterparty_1 | [2023-02-10 16:18:52][INFO] Block: 775899 (11.64s, hashes: L:65c47 / TX:641ec / M:66b86)
counterparty_1 | [2023-02-10 16:21:33][INFO] Block: 775900 (9.45s, hashes: L:c9f81 / TX:84ff4 / M:463a0)
counterparty_1 | [2023-02-10 16:23:35][INFO] Dispenser: 1KA77777WAZf9jSphZCnywmvyhrKjYv8jc opened a dispenser for asset XCP with 361.00000000 balance, giving 1.00000000 XCP for each 0.00014295 BTC
counterparty_1 | [2023-02-10 16:23:35][INFO] Cancel: 6f7cb977f162f67c7871a215453bbfa8b35163227245a8d7a6f35638c7be9169 (bbaf95f741fa29e919f86b8c1ebb6ebf536dcc579a501d71918417e9f0a366cc) [valid]
counterparty_1 | [2023-02-10 16:23:35][INFO] Order: 1PK4LuSrVXMKFoyeQxrZAPLoyhX9vW1433 ordered 1 DOTPEPE for 375.0 XCP in 5000 blocks, with a provided fee of 0.00005544 BTC and a required fee of 0.00000000 BTC (b51ec45386e7f604eac8a523c8698259a853ece64abc1a53fc5c96b8d179213b) [open]
counterparty_1 | [2023-02-10 16:23:35][INFO] Order: 1PK4LuSrVXMKFoyeQxrZAPLoyhX9vW1433 ordered 1 PEPETHOR for 75.0 XCP in 5000 blocks, with a provided fee of 0.00005544 BTC and a required fee of 0.00000000 BTC (354c0de3ba591f70c1aa33dffab50b63d4d2b8cc6129d27a4183975d6c868f68) [open]
counterparty_1 | [2023-02-10 16:23:35][INFO] Order: 1PK4LuSrVXMKFoyeQxrZAPLoyhX9vW1433 ordered 1 FIGHTSYSTEM for 20.0 XCP in 5000 blocks, with a provided fee of 0.00005016 BTC and a required fee of 0.00000000 BTC (f4137dbb84f65623d1b5802da9f4eb1c56e29a9f95562d3cad1da479ae226489) [open]
counterparty_1 | [2023-02-10 16:23:42][INFO] Block: 775901 (11.21s, hashes: L:cb8fa / TX:9fbd2 / M:22d24)
counterparty_1 | [2023-02-10 16:26:36][INFO] Expired order: bd5b025ac9230dd252c9a1c65497983d30a177bd9cdac94fdce04ad2992e8829
counterparty_1 | [2023-02-10 16:26:36][INFO] Expired order: c635e7bfd21570ba7c4c95f99a65947b2fdd94d52450a0aeab688fcb1be50d82
counterparty_1 | [2023-02-10 16:26:36][INFO] Expired order: 947c6229dfa1a5aaf53c02d014b69075f086e7753185c8cfd599877cb146fbd3
counterparty_1 | [2023-02-10 16:26:36][INFO] Expired order: 3767132e37b6394d94786b18e6cc1981ed21f086b9468dbd8a0c3ba47cb9e844
counterparty_1 | [2023-02-10 16:26:36][INFO] Expired order: 72e593d66a32316f7c43b081c62af81a31d1f49126611e99c0672285adf77070 -
that is from fednode tail counterparty
-
you can see the timestamp printed in the logs is when the message occured 🙂
- 14 February 2023 (2 messages)
-
what is the max number of chars you can have in a "destroy" memo field? -
34 bytes long?
- 15 February 2023 (12 messages)
-
Hey a weird thing happened with a transaction from Theo just this week. He made a multisend which included a send of RISAVIX to me. He put 1 in the multisend, and because its divisible only 0.00000001 was showing up in the send. I let theo know and he sent the rest before the multisend had confirmed. The rest was showing as 1.00000000 even though he only had 0.99999999 in his wallet after already sending the 0.000000001. That second one confirmed and then the multisend disappeared, unconfirmed and no record of it -
This is the send of the 1.0000000 that should have been 0.99999999: https://xchain.io/tx/94b538973617710dfc5b9bef1b579c88e8dfd4abe61e775f545729f848a8dca9
-
That caused the other one to disappear
-
If the first Tx was unconfirmed then he still had the full 1.00000000 to send so since the second confirmed first it probly made the first Tx invalid
-
Simple as that :) Thanks Joe
-
can anyone confirm this ?
-
I used opreturn > 80 bytes on testnet. Is this possible on mainnet too?
https://testnet.xchain.io/tx/31566 -
@pataegrillo can you please take a look into this pls…. I’ve heard a few stories of multisend disappearing in the past year, and experienced it myself once as well, but never was able to repeat…. Here we have the issue again… would be nice to know why cp parsing ignored.
-
what address was the destination of the mpma send? -
saw the logs and I know what happened: the mpma transaction got confirmed 3 blocks after the send. The send (94b538973617710dfc5b9bef1b579c88e8dfd4abe61e775f545729f848a8dca9) got confirmed on block 776,335 and the mpma (f85446cb1680f0993a4a48c69e177463ba234d650a93401355b814da1f945b10) on block 776338
If you search for the entire database for a 0.99999999 quantity, there is not a single one, so there must be some floating point precision problem somewhere from the api to the parsing that's changing that 0.99999999 to 1.0.
so, your send got confirmed with a 1.0 quantity first and the mpma got confirmed later but was invalid because there was no funds -
and the mpma just did this: now you see me (unconfirmed), now you don't (confirmed and invalid)
-
okay, that makes sense
- 16 February 2023 (31 messages)
-
Some thoughts on a random lottery dispenser
https://forums.dogeparty.net/t/dip-lottery-contract/69DIP - Lottery ContractA Lottery would be very similar to a regular dispenser with one major difference - it’s random whether you receive the token or not. Say you set up a lottery for a DOGEMEME card. You specify the price, 10 doge, and the chance to win the card, 5%. Someone sends 10 doge to the lottery, and the protocol register the request. Hardcoded in the protocol is a random number generator, and the output [0,1) is determined by the block hash and transaction hash. In this case, if the result <0.05 the token...
-
when we run out of things people want and need let’s build this 🤔 -
interesting take- why do you expect backlash? I thought the idea was to keep it very basic, not recreate the EVM hairball. John’s vision for this VM was sound IMO.
-
It would depend on the implementation for sure, but adding complexity is always a risk which may or may not be worth taking
-
my hot take: adding features for the sake of adding features surely just lead to a less stable protocol - it feels like that’s what we’re doing
-
perhaps the best use of these very scarce dev resources is to make fewer, but more deliberate and significant changes, that’s my view
-
stability is one of the most desirable properties a protocol can have
-
lets give that up only when compelled to do so by the power of an idea
-
I think we agree
-
I honestly think a VM will attract a new group of developers. Even though most smart contract functionality is really just window dressing, it seems to me that we should either implement a simple VM scheme, or launch another standardized token type that cherrypicks features from the current smart contract landscape.
The VM is more forward-looking IMO and unlocks a new playground for would-be devs who take a look at Counterparty as a platform option. Either choice positions Counterparty well wrt competing for more developers, which should lead to increased usage.
Is there an appetite for revisiting the VM discussion, and dusting off the old plans despite not having the architect around to flesh out the details? -
Oh a VM is happening, prolly will just get built/tested on Dogeparty first…. And if the CP community wants it, we can port it over…. Javier n I have been discussing it for a while and are setting aside a few weeks to dive into VM design and hammer out a rough framework… definitely encourage more discussions and suggestions tho… 😀👍🏻
-
Proof-of-concept VM Development
So i’ve recently started to develop a minimal pure python Virtual Machine tailored specifically for counterparty. I’m starting this thread to keep note of development and design decisions, and also to get input from the community regarding what should the VM do. FAQ Why not use EVM? EVM was designed with ethereum blocktimes and specifics in mind. CP has already a lot of groundwork regarding tokens, bets and a lot of useful functions that don’t need to be recoded in a smart contract. Isn’t...
-
@mightbemike thoughts on this additional cp feature? https://github.com/CounterpartyXCP/counterparty-lib/issues/1214Add support for `custom_outputs` in advanced create parameters · Issue #1214 · CounterpartyXCP/counterparty-lib
We currently support custom_inputs which allows a user to specify exactly what inputs to use in the transaction. We should also add support for a new custom_outputs parameter where a user can speci...
-
This sounds crazy useful and seems like a winner for Counterparty. The "royalties" feature is highly contentious for good reason, but there is an understandable appetite for it too. Other uses, hmmmm... great food for thought.
-
This is not a consensus change, just a wallet feature right?
I added this to countertools back in the day. -
no consensus change, but not just a wallet feature... the CP API would be updated to allow users to specify custom_outputs which would be tacked on as additional outputs to a standard CP transaction.... so, you could do a send, and tack on an output for an enforced royalty payment to an artist, etc..... no real change to any of the way CP parses transactions, just a way to tack on additional outputs to existing CP transactions
-
not a fan or royalties either... but they are a good example 🙂
-
its good for creating gift cards and stuff like that
-
I like the idea of an optional? 1% "platform tax", specified when the asset is created, paid on each resale, to fund maintenance and/or development of critical parts of Counterparty ecosystem including the protocol itself.
It may be controversial, but worth trying because it can be a more sustainable source of funding development. JDog scraping donations together to maintain, develop, and oversee the development of most the core of "Counterparty" is not scalable or sustainable over time; here is a chance to put Counterparty on sounder financial footing. -
the native "token" XCP should be playing this role really, but one way or another a funding mechanism sounds good right?
-
While I would love more dev funds... not sure I could be supportive of a forced tax on CP transactions.... tho, I could probably integrate some features into freewallet that would help fund dev.... defaulted on, but able for ppl to turn the feature off... Also, as far as dev funding... I think the VM will help with that some if/when we roll it out.... the VM will need a GAS token, we probably wont want to use XCP as the gas (XCP is generally destroyed on actions, not recycled back into the ecosystem, and I think we should keep that deflationary model), and instead will probaly just airdrop a GAS token on XCP holders to make the distribution fair and withhold a small percentage in a dev fund to help fund VM development/maintenance going forward... after that, the VM could charge GAS for executions, and the GAS could then be auto-recycled into a VM dev fund..... I know the VM is a big undertaking and I would like for the VM to fund its own development and maintenance rather than having to rely on the CP community for donations (as you mentioned, its not a sustainable model) .... Donation based model is great in bull market when ppl flush with funds... but in bear market, all donations dry up... def need something more sustainable.
-
Nothing is set in stone yet... just spitballing... but, this is the general direction Javier and I are leaning.... one time VM dev cost from community, airdrop GAS on existing community, after that VM dev fund supports itself.... similar to how the Dogeparty 'bern' Community funds are being used to support DP dev now 🙂
-
If this got traction I think more and different objections would be voiced too
-
is it right to think that projects could bake in their own funding mechanism using this feature?
-
i.e. create their own project "wallets" (standalone app, project website itself, browser plugin, etc.) and populate that list of outputs
-
for example I could launch a project and people who mint official assets in my collection automagically create tokens that are known to fund some crazy roadmap/plan with 5% of each sale
-
yes, you are correct.... someoone could create a standalone app/website/plugin which handles doing some task, and generates a CP transaction and tacks on additional outputs for their fee or whatever.... they could then throw that unsigned transaction to a wallet via the counterparty: URI, and users could sign and broadcast in their own wallet (this works with freewallet currently).... or could throw to some meta-mask style browser plugin for signing.
-
I also think it is important to get this issue fixed.... currently CP dispensers only pay attention to the first output... once we get this issue fixed, we could combine it with the custom_outputs feature to allow the type of functionality I think your talking about (having a CP transaction which has additional outputs, which could for instance, trigger a dispense from a dispenser)... Would make things like "Issue named asset using only BTC" easier to implement (tack on extra output to a CP issuance transaction which purchases the necesary XCP from a dispenser before processing the issuance transaction which requires the XCP)
It could possibly remove one of the biggest complaints about counterparty... the requirement of XCP for named asset issuances. -
Just 1st dispenser dispenses when batch-sending sats to multiple dispensers · Issue #1148 · CounterpartyXCP/counterparty-lib
This is the transaction (generated with a simple blue wallet) https://blockstream.info/tx/11eb2b730e2e383a657c51d7b04bd55271d1e86ac9a2c74d3e3f6c78e88e23ff where correct exact sats were sent to 5 di...
-
6y ago i sent BTC along TIGERCOIN 😉
https://youtu.be/2HybXrFIjgQSend Your Token along with Bitcoin'Piggyback' transaction is a Bitcoin transaction where your own custom token is sent along with Bitcoin. It's a perfectly valid Bitcoin transaction. Your benefit is that you can add a coupon or discount card at no additional cost.
- 22 February 2023 (12 messages)
-
allow triggering of dispensers by all tx outputs, not just the first output by pataegrillo · Pull Request #1222 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
Nice work Javier! I'll do some additional testing on this on testnet... and we'll get it in the next release 🙂
-
so does this just mean every output is checked against open dispensers?
-
correct
-
sweet
-
previously we were able to store transactions data in the transactions table cuz all we ever cared about was one btc_amount.... but, now we have transactions with multiple outputs and multiple btc_amounts... so we came up with an additional transaction_outputs table to track the outputs and btc_amount for easy reference 🙂
-
can you create more then one issuance in a single transaction ?
-
No
-
This is just for dispensers currently
-
Yh np assumed as much :)
-
When live on testnet? I would like to try some edge cases.
-
You can pull down the pr on your own node and test…. No rush on getting a release out, got some other bug fixes n updates to make first… will prolly look to test n get a release out near April 1st…. Got some freewallet updates to make first, and oracled dispensers and mpma on dogeparty to test and put out those releases first…. They’ve been waiting since before Christmas for mpma n oracled dispensers…
- 23 February 2023 (1 messages)
-
I opened a forum thread on batch-sending to dispensers
https://forums.counterparty.io/t/batch-sending-to-multiple-dispensers/6499
I have an alternative proposal for compressing/chaining multiple counterparty txs inside one btc tx.
Can formalize this as a CIP if the community is interested.Batch-sending to multiple dispensersBefore implementing batch-sending to dispensers, it would be wise to analyze the benefits, costs, risks and alternatives. Here’s the github issue : Just 1st dispenser dispenses when batch-sending sats to multiple dispensers · Issue #1148 · CounterpartyXCP/counterparty-lib · GitHub My understanding is far from perfect. Would be nice to have others chime and correct me wherever I’m wrong. Benefits the current first-output only rule may appear as a bug for end-users. batching-sending makes it ...
- 27 February 2023 (18 messages)
-
Lock token description feature?
Over the last year I have heard a few community members mention that it would be a nice feature to have to be able to lock the asset description, so that it can no longer be edited. This would allow issuers to issue a token, and lock both the supply and the asset description independently, and would help give potential token buyers/holders confidence that not only can additional supply not be issued, but that the asset description will never change. Any artwork or metadata that the token points...
-
how many times can an unconfirmed input be used?
EG i have a an address with 1 UTXO, how many unconfirmed transactions can I create from it?
is there a network limit or even a XCP limit? -
ok super i thought it was about 10 -15 but when trying to mint 4 things in a row i seem to upset counterparty
-
ah i think i know why
-
oh no maybe not then "Error while trying to broadcast signed transaction"
-
Think i might be hitting it too quickly
-
how long is that ?
-
lool
-
jeeze i just googled that
-
proper lolling.. thanks Aryan!
-
just so you know adding a refractory period to my code worked
-
pretty much
-
lol
- 28 February 2023 (3 messages)
-
generally about 10-15.... but the other day I was able to chain 24 together... tho guess I could have been using a couple utxos and not just a single utxo chain.
-
I will work on getting better error handling to bubble up in freewallet... but, if you get an issue with broadcasting, you can do the following:
1. Click Freewallet Logo->Debug button
2. Click Console
3. Try transaction again
4. Look at console and copy the signed tx ("signed_tx=" in console)
5. Paste your signed tx into a broadcast tool like https://live.blockcypher.com/btc/pushtx/
That should then give you the specific reason that your transaction is having issues broadcasting.... issues broadcasting come directly from Bitcoin. -
Ok sweet, i was only using freewallet to sign the tx but yh leaving a 15 second "refactoryPeriod" between transactions worked mighty fine :)
