No, it never gets pruned. One of the appealing features of blockchain is that the history stays there forever.
The size of the blockchain grows roughly linearly (ignoring the effect of adoption), whereas storage capacities follow Moore's Law and grow exponentially. So the expectation is that, yes, the blockchain will grow bigger and bigger, but that that is ...
When validating an address, the script will access the data being
carried by the output, the transaction being validated, and some
additional pieces of data called redeemers, which the transaction
provides for every input. By looking up all this information, the
script has enough ...
In simple terms, redeemer is the data that the user of the smart contract provides to the smart contract.
In the simple UTxO model, redeemer is your signature. By providing your signature, you prove that you own the UTxO and in return you are allowed to spend that UTxO.
EUTxO takes this one step further. How are you going to spend an EUTxO? You have to ...
Every transaction needs to include at least 1 ADA (See: Is there a minimum amount of ADA I can send in a transaction?).
No, every UTxO (i.e. output you're sending asset to) needs to be atleast 1 ADA. This was included to prevent dust and spamming on blockchain. In future , it will be possible to offload this minUtxo fee to block creators who may opt-in to ...
That is correct. For a UTxO to be consumed it first has to exist on the blockchain. For it to exist on the blockchain the transaction that created it must exist in a block that has been confirmed by the network.
Is there any limit to the number of UTXO's sitting at a script address?
There shouldn't be any practical limit.
UTxOs aren't stored in some memory at an address. The address determines who can spend a UTxO, not where it resides. And that address is included on the UTxO, not vice versa.
In other words, when you send UTxOs to an address there is no check on ...
For the second part of your question (what's to stop the size of the blockchain from growing indefinitely to the point where it's impractical to store on consumer hardware?), there are concepts like sharding and side chains and .... You can watch Charles Hoskinson talking about this topic here.
UTxOs are always associated with some address or "public key".
Traditionally, on Bitcoin and Cardano that meant a wallet address. And someone could only spend a UTxO in a transaction signed by the private key of the associated address. When you send BTC or ADA to someone, you are really just creating new UTxOs that can only be spent by that person.
Emmanuel is correct, based on the coin name there is an amount of ADA that needs to be sent to every target address.
My native token requires 1.444443 ADA to be sent to each and every target address, i.e. if I want to send 1 Bingo Token to 100 individual addresses, I have to send 1.444443 ADA to each target address, irrespective of whether I batch them all ...
Before (E)UTxO - There Was UTxO
Understanding how a UTxO model works (such as BTC) may help you understand the implementation of (E)UTxO in Cardano.
The UTxO Model
A UTxO model, meaning: unspent transaction outputs from previous transactions1 will typically implement a validator and a redeemer for any given new transaction (at least, this is the case in BTC)....
The simple answer is yes, a Cardano pool operator could front-run a transaction in the mempool to their advantage. They would need to customize the haskell code to allow their node to order the transactions in the mempool as they wanted them.
That being said, there is some risk to the pool operator by doing this. There is a 5% chance that any block made by ...
Thanks for your question.
send about 6000ada to bob then he sends the two UTXOs to bob i.e. 5000ada and 2000ada (total 7000 ada) and he receives a new UTXOs of 1000ada back, right?
Correct. For regular transactions, the sum of the transaction inputs values must match the sum of the outputs (This isn't strictly true, as there are fees and the possibility to ...
This sounds like a two part question:
Is there any limit to the number of UTXOs stored at a script address
Is there any limit to consuming UTXOs stored at a script address
For the first one, yes and no. While you can theoretically store as many UTXOs as you like at a script address, there are some resource constraints you're likely to run into:
The size ...
The serialization lib is written in Rust and compiled to web assembly. Rust manually manages its memory, and I'm assuming that you need to do the same here. If you look at the typescript types you can see that every object has a free() method.
The ptr is a pointer to memory. If you need to access information of the UTXO you need to use the provided functions....
You can only grab the gift once it's confirmed on the ledger. Search for awaitTxConfirmed in the source code.
That effect may have configurable level of confirmation in the future as indicated in the source code.
Cardano is using what we call a chimeric ledger, which means it uses both account (similar to Ethereum) and UTxO (similar to Bitcoin) style accounting systems.
This enables the ledger to take advantages of the UTxO system but at the same time be storage efficient where it comes to specific aspects of the ledger, such as rewards.
I highly recommend a video of ...
Every Native Asset is sort of conjoined to 1.4XXXXXX ADA from my experience and so it basically impossible to simply just send the native asset by itself. It’s a part of it. You’ll end up having to cover transaction fees with part of your 2 ADA.
This is all from my time manually minting and sending assets with the CLI. Will advise further research.
We could use your redeemable approach and make it so the seller cant rig it.
This is the idea, you will need to create 2 different minting policies, one for your NFTs and one for the redeemable NFTs, it is important that both policies do not allow duplication of the asset names (you can do that with something like this https://forum.cardano.org/t/mary-era-...
You can think of regular Bitcoin-like UTXO's as a subset of all possible eUTXOs possible to construct on Cardano. Transactions that simply transfer ADA from one wallet to another (and nothing else) are examples of bitcoin-like UTXO's. eUTXO extends this core functionality by allowing one to attach arbitrary data and logic to each transaction, enabling ...
No, this is not possible right now without verifying just the hash.
Also, an attack vector that comes in mind is that someone will see the tx, validate it before it is included in the blockchain and make the block with the correct response first.
We may need different models than what has been done in Uniswap, Keep in mind that Hyrda is coming and can get us around this problem. Unlike other L2 solutions for other blockchains, Plutus code runs with Hydra out of the box so by then this may not be an issue.
Prof, Aggelos Kiayias explains here I recommend watching the whole video.
You are speaking about what we call Coin Selection Algorithms and they are described in CIP2.
There are several implementations floating around on Github, such as BerryPool implementation of the Random-Improve coin selection algorithm or what Yoroi does.
I already found the answer and will leave it here in case anyone ran into the same problem.
You need to update the node-cli version to the lastest version (currently) 1.31.0 and then you have the following options available:
[--tx-out ADDRESS VALUE
[ --tx-out-datum-hash HASH
| --tx-out-datum-hash-file FILE
off-chain scripts just instruct on what to do and has no influence under transaction output.
You should be able to specify multiple outputs going to the script address in your off-chain code. Just note that they will need to each have separate datums if you want to be able to spend them later. Something like
let a = Constraints.mustPayToTheScript datum_one ...
Official documentation is silent about it.
Since many UTxOs can exist within one wallet address, the same way they can exist within a script address. You can potentially have even 10,000 Tx inputs per script address, but in reality, I'm sure, their number is below 1000, because it'll take a fair amount of network power to scan all inputs and outputs of each ...
If I understood your question correctly you are looking for the address used to send the ADA.
Your first image shows an array of inputs used in the transaction and each input points to the transaction with the output index.
So to find out the sending address, you can copy the id(transaction id) and search on testnet.cardanoscan.io OR you click on the below ...
It depends on what you're exploring. If you're exploring forged coins in Cardano, look at this page of Blockchain Explorer, for example – as you can see there's no inputs in Tx. And this is also possible through constructing a raw transaction via cardano-cli – the only question is what will you achieve with such a transaction.
By the way, in Bitcoin network ...
The root key of a wallet is derived from BIP39 keywords. Then additional keys are derived beyond that. You would need to check each one individually for funds. You can use the cardano-serialization-lib for this. Many lite wallets like yoroi or ccwallet.io use this. More information about BIP39 can be found in my youtube video on the subject. https://youtu.be/...