text:
Empty txInfoSignatories after building transaction with cardano-cli
In the Plutus Pionner Lectures, Lars instructed us to use txSignedBy in order to ensure that a user signed the transaction. The function tries to find a public key hash in the txInfoSignatories list, if it's able to find, it returns True.
Everything was working in the emulator, but now, when I tried to manually build and sign the transaction with cardano-cli, the transaction doesn't appear to add the public key hash from the user who signed it to txInfoSignatories and the script validation fails. My question is: how do I add the user pubkeyhash to txInfoSignatories with cardano-cli? No information regarding the signature appears when I execute cardano-cli transaction build -- help

------ UPDATE------
Since version 1.31 of cardano-cli, there is the following option to sign the transaction when it is built, so you can avoid that error from the script:
--required-signer FILE   Input filepath of the signing key (zero or more)
                         whose signature is required.

-----------------------
It's related to this bug: Cli to pass required signer (reqSignerHashes) to plutus script for txInfoSignatories
In a near future, there will be a --required-signer option in cardano-cli
As a workaround try to combine toPubKeyHash and txOutAddress function to get the PubKeyHash from any output.
info :: TxInfo
info = scriptContextTxInfo ctx

txOuts :: [TxOut]
txOuts = txInfoOutputs info

outPubKeyHash :: Maybe PubKeyHash
outPubKeyHash = toPubKeyHash $ txOutAddress $ head txOuts

@georgeos answer was correct, but from node version 1.32 there is
--required-signer-hash HASH
                           Hash of the verification key (zero or more) whose
                           signature is required.

(so you don't need to know users signing key, just pass the PubKeyHash)


text:
How to convert a cardano address into a public key hash?
After spending some time learning Plutus with emulators, I decided to start learning how to actually deploy and use the scripts in the testnet. In this process, I installed cardano-cli and created multiple key files, such as "payment.addr", "payment.skey", "payment.vkey", etc. But now, the validator script that I created requires as one of it's parameters a Plutus AssocMap associating public key hashes to integers.
My question is, based on the keys I created, how can I find out their PubKeyHash? I believe this is related to "payment.addr", but I'm not sure.

How to get this value when using e.g. Nami Wallet?

Is there a way to get key-hash from payment.address only?

@AdamMachera See my new answer

I think you're looking for this:

cardano-cli address key-hash --payment-verification-key STRING
cardano-cli address key-hash --payment-verification-key-file FILE

You should use your payment.vkey

This is the cborHex value in the .vkey file yes?

If anyone is trying to do this using cardano-serialization-lib and Nami:
const PUBKEY_HASH = async () => {
  const cardano = window.cardano;

  const pkh = Loader.Cardano.BaseAddress.from_address(
    Loader.Cardano.Address.from_bytes(
      Buffer.from(await cardano.getChangeAddress(), "hex")
    )
  )
    .payment_cred()
    .to_keyhash();

  return pkh;
};

Assuming you are using a loader like the one from spacebudz and you are importing Buffer import { Buffer } from "buffer";
UPDATE
Made a more abstract version that takes a string (the bech32 address) and returns another string (the public key hash)
function addrToPubKeyHash(bech32Addr) {
  const pkh = Loader.Cardano.BaseAddress.from_address(
    Loader.Cardano.Address.from_bech32(bech32Addr)
  )
    .payment_cred()
    .to_keyhash();

  return toHex(pkh.to_bytes());
}

Sorry fromHex is defined as const fromHex = (hex) => Buffer.from(hex, "hex")

And toHex const toHex = (bytes) => Buffer.from(bytes).toString("hex")

You can use the "cardano-address address inspect" syntax to get the public key hash from an address without requiring the verification key. Requiring the verification key assumes having access to the file while addresses can be shared without having to know the owner.
This link can help: https://github.com/input-output-hk/cardano-addresses

I am working on this as well... I am not sure but this seems quite promising
https://input-output-hk.github.io/cardano-addresses/demo/
Maybe this is usefull as well
https://cips.cardano.org/cips/cip19/#shelleyaddresses

If you are using the serialization lib, my answer may help

Couldn't you just pass the address to Plutus and then convert it there to a public key hash using the function in Ledger.Address:
{-# INLINABLE toPubKeyHash #-}
-- | The PubKeyHash of the address, if any
toPubKeyHash :: Address -> Maybe PubKeyHash

The address is serializable so you can pass it easily and get a proper instance of Address that you can use at your will in your Plutus code.

Are you sure this Address is a bech32 string? I don't think it is https://staging.plutus.iohkdev.io/doc/haddock/plutus-ledger-api/html/Plutus-V1-Ledger-Address.html#t:Address

I don't know if this deserialisation is this easy, actually. I haven't tried yet. But, there must be a function in Plutus to deserialise the string to the Address class.

This is getting strange. Why is it so difficult to find a function in Plutus that parses the address representation to the address class ?

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
NativeScript vs PlutusScript
In cardano serialization lib what is the difference between NativeScript and PlutusScript? Is there a way to convert from one to the other? I'm trying to load a minting policy script I made as a NativeScript, but I couldn't find any examples of this, while I can see that, spacebudz, for example uses PlutusScript to load their contracts.

I think NativeScript is a simple multisig scripting language while PlutusScript is a Turing complete scripting language. You can find more details and examples of NativeScript here

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
cardano-serialization-lib-browser loaded as empty module in NextJS
I'm trying to use cardano-serialization-lib in a NextJS project I'm working on, but I'm receiving an exception before initializing the application TypeError: Cannot read properties of undefined (reading 'from_address') in the following code
export const MINTING_POLICY_HASH = () => {
  const vh = Loader.Cardano.EnterpriseAddress.from_address(
    Loader.Cardano.Address.from_bech32(createAccountPolicyBechAddr)
  ).payment_cred()
  // ...
}

After digging a little bit, I found out that Loader.Cardano was returning a module, but an empty one, Loader is defined as follows:
class Loader {
  async load() {
    if (this._wasm) return;

    this._wasm = await import(
      "@emurgo/cardano-serialization-lib-browser"
    );
  }

  get Cardano() {
    return this._wasm;
  }
}

When I tried to print Loader.Cardano (after loading it with Loader.load() and waiting for it to actually be loaded), it gave me this:
Module {
  __esModule: true,
  Symbol(Symbol.toStringTag): 'Module'
}

Meaning, as I said, the module we are importing ("@emurgo/cardano-serialization-lib-browser") is weirdly giving us an empty result. I assume this has to do something with webpack or NextJS and the way they are handling WASM modules, here's my next.config.js:
/** @type {import('next').NextConfig} */

module.exports = {
  reactStrictMode: true,

  webpack(config) {
    config.experiments = {
      asyncWebAssembly: true,
      topLevelAwait: true,
    };

    return config;
  },
};

I used cardano-serialization-lib twice already with gatsby and create-react-app, but never with NextJS, if anyone could help I would appreciate.

I do not know why, but this worked for me
this._wasm = await import(
      "../node_modules/@emurgo/cardano-serialization-lib-browser/cardano_serialization_lib_bg"

:s ES6 notation did not work.
my whole loader:
class Loader {
  async load() {
    if (this._wasm) {
      return;
    }
    /**
     * @private
     */
    this._wasm = await import(
      "../node_modules/@emurgo/cardano-serialization-lib-browser/cardano_serialization_lib_bg"
    );
  }

  get Cardano() {
    return this._wasm;
  }
}

export default new Loader();

Good luck!

You saved my life, thank you. Spent two days trying to figure out what you did in minutes lol

authors: خاور دریجانی


text:
Convert Redeemer, Datum or Script Parameter to JSON
By following the alonzo-testnet exercises, I'm right now having to build a transaction with cardano-cli. One of the arguments necessary to consume a script is the datum, another is the redeemer, both of which should be in a JSON file (or value).
Is there any reference of how Data should be expressed in JSON? Because I tried converting it with Data.Aeson in Haskell, but received the following error
JSON object does not match the schema.
Expected a single field named "int", "bytes", "string", "list" or "map".
Unexpected object field(s): {"contents":{"getPubKeyHash":"3e7181860513a17dfa44d69232429e5c328e79c748d4a176950c42b6"},"tag":"Collect"}

Also, is there any library to make my life easier, so I can be able to easily convert my redeemers into JSON?

Reading some old messages in discord, someone mentioned that I could use encode (scriptDataToJson ScriptDataJsonDetailedSchema $ fromPlutusData data), taken from here, so I made a redeemerJSON function defined as follows:
redeemerJSON :: DistributionRedeemer -> ByteString
redeemerJSON dr =
  encode (scriptDataToJson ScriptDataJsonDetailedSchema $ fromPlutusData (PlutusTx.toData dr))

Of course some imports are necessary, but I believe you can use this same approach for the datum and other script parameters too.

I would make it even more general to:
plutusDataToJSON :: PlutusTx.ToData a => a ->  Data.ByteString.Lazy.Internal.ByteString
plutusDataToJSON = encode . (scriptDataToJson ScriptDataJsonDetailedSchema) . fromPlutusData . Plutus.toData```

The Cardano-node github is the best resource that I have found
JSON conversion

Script data is similar to JSON but not exactly the same. It has some
deliberate limitations such as no support for floating point numbers
or special forms for null or boolean values. It also has limitations
on the length of strings.
On the other hand, unlike JSON, it
distinguishes between byte strings and text strings. It also supports
any value as map keys rather than just string. It also supports
alternatives / tagged unions, used for  representing constructors for
Plutus data values.
continues ....

Further extensive details in Cardano-node github file ScriptData.hs


text:
Building alonzo transaction using cardano-cli and signing it with serialization-lib
I created an API that based on a request builds the body of a transaction with cardano-cli and returns the cbor to the front-end. In the front-end, I'm using the cardano-serialization-lib to load the transaction and send it to the wallet, requesting a signature.
This is the code in the front-end (I'm using the new --cddl-format option, so no need to clear the witness set)
export async function signTx(api, cbor) {
  // load tx cbor
  const tx = Loader.Cardano.Transaction.from_bytes(Buffer.from(cbor, "hex"));

  const witneses = await cardano.signTx(
    Buffer.from(tx.to_bytes(), "hex").toString("hex")
  );

  const signedTx = Loader.Cardano.Transaction.new(
    tx.body(),
    Loader.Cardano.TransactionWitnessSet.from_bytes(
      Buffer.from(witneses, "hex")
    )
  );

  const txhash = await api.submitTx(
    Buffer.from(signedTx.to_bytes(), "hex").toString("hex")
  );

  return txhash;
}

The wallet asks me to sign the transaction nicely and I'm able to confirm it, but when it tries to submit the transaction, it gives me this error
transaction submit error ShelleyTxValidationError ShelleyBasedEraAlonzo (ApplyTxError [UtxowFailure (PPViewHashesDontMatch (SJust (SafeHash \"e84ed35a172ed46da854a132db880a608f73e0e61d385c9475a5b14fe4b9e4a9\")) SNothing),UtxowFailure (WrappedShelleyEraFailure (MissingScriptWitnessesUTXOW (fromList [ScriptHash \"1ef6f56f2e174d5e0328f24aa30d55b81f3bf871361f9280dd4090c2\"]))),UtxowFailure (WrappedShelleyEraFailure (UtxoFailure (UtxosFailure (CollectErrors [NoRedeemer (Minting (PolicyID {policyID = ScriptHash \"1ef6f56f2e174d5e0328f24aa30d55b81f3bf871361f9280dd4090c2\"})),NoWitness (ScriptHash \"1ef6f56f2e174d5e0328f24aa30d55b81f3bf871361f9280dd4090c2\")]))))])

I suppose it has to do with the fact that my transaction has minting policies (with redeemers) and an embeded datum and for some reason they are not present. If that's the case, how can I add them? Do I need to add the redeemers once in cardano-cli and again in the serialization-lib? If it's not the case, what am I doing wrong?
Also, if I do need to add the redeemers to the witness-set in the serialization-lib, is there any way I can send a "witness file" from the back-end and simply load it?

both tools serialize in different ways.. even hashes in different ways, i would suggest to take a look to the CBOR And try to see whats going on there.


text:
Can you include a minting policy in a transaction without minting or burning any tokens?
I want to use the minting policy to abstract the script logic away from the validator and only validate what's necessary for a specific transaction. Right now, I'm able to do this by minting a token I call ticket and creating the validator in such a way that it makes sure this tokens is being minted.
Since my purpose is not to mint a token, this ends up increasing the transaction size without any added value so I wonder if it's possible to include the minting policy in the transaction, verify that somehow in the validator, but not mint or burn any tokens.

I had a similar issue where I needed to break up the validator logic to keep under the maxTx size limits.  I was able to do this by testing for the presence of threadtokens so that each of validators could "communicate" with each other.   I also implemented some performance improvements that reduce the overhead as well.
The project is called The Open Source Cardano Lottery and you can checkout the source code here:
https://github.com/lley154/cardano-lottery

I know I'm not answering your exact question, but I think I can help you achieve your goal of "abstracting the script logic from the validator and only validate what's necessary for a specific transaction." Plutus pioneer program cohort #3 week 1's code is a good example of this
https://github.com/input-output-hk/plutus-pioneer-program/blob/main/code/week01/src/Week01/EnglishAuction.hs
You'll see that Lars used a custom data type for his redeemer, that allowed him to have different logic for whether the validator script was called with the intention of bidding or closing the auction.

Thanks for your answer. I see value on what Lars did, but my purpose was to reduce the script size. If I put all the possible conditions into one script, it could reach the transaction limit, so I prefer to have multiple minting policies that are only called when one of the conditions is met.


text:
Mint tokens using plutus scripts with the serialization lib
As I understand, in order to mint a token with the serialization-lib, you must use the function set_mint_scripts, providing a NativeScripts object. This collection of NativeScript objects should determine until what time a token can be minted and by whom.
With the introduction of Plutus, though, we have a new way of minting assets, which is using Plutus scripts. They allow or not the minting and burning of the assets based on arbitrary logic. These scripts are defined in the serialization-lib as PlutusScript and there doesn't seem to be a way of converting a plutus script into a native one (which makes sense since they are different things).
Is my understanding correct? And, if so, did I miss any function or object that is actually able to do what I want? If not, are there any workarounds I could make use of?

Im having the same question, did you found something about this?


text:
Rust off-chain solutions
I am interested in learning Rust and I thought a good idea of doing so would be to build something on Cardano. What libraries and resources would you recommend for someone like me? I am specially interested in building, balancing and evaluating transactions (including possibly smart contracts).

Naumachia is specifically designed to make off-chain code easy with Rust. It uses CML under the hood for actually deploying/transacting, but that's much too low-level for the average developer IMO, and Naumachia abstracts away a lot of the headache with declarative APIs. There are just a number of features that are still WIP.
Naumachia also comes with testing infrastructure for creating ScriptContexts for testing your On-Chain code, as well as mock chains for testing your contract as a whole. It also syncs with the trireme cli for managing your test environments/keys.
There are multiple "Sample dApps" which are functional examples of Naumachia here. A lot of progress has been made since the README was written, but everything on there is still relevant to get your started. I'm hoping to add more tutorials soon, and hopefully a Demeter template as well.

You can try Cardano Multiplatform Lib.
It can be deployed to multiple platforms (Rust crate would be what you are interested in) and it handles:

Serialization & deserialization of Cardano core data structures
Useful utility functions for DApps and wallets


text:
Define a native token minting policy restricted by NFT
I have found examples indicating that a minting policy can be single shot or restricted by PubKeys, however I would like to secure minting and burning of a token based on if a specific NFT is present in the redeemer.
My current thinking (no code written yet) would be to create an OnChain validator to check for the NFT and set the minting policy to forwardingMintingPolicy.
This makes me a little nervous because from what I understand once a minting policy / token is established it can never be changed which means the validation script can also not be changed.
So with this in mind would it be recommended to make the token contract as simple as possible ie, Mint, Burn only validated as above, then keep any potentially complex behaviour in other contracts that can be changed. Or am I missing something entirely.

Define a native token minting policy restricted by NFT

This is how the Liquidity Token minting works in the Uniswap example.
isUnity v usCoin

checks that there is included one usCoin. The policy also includes some additional flexibility, but that's the general idea.
I think this is going to be a very common pattern in smart contracts.

I've actually been thinking about how to abstract this exact pattern into some library/framework. There is a lot of annoying boilerplate involved in the off-chain and on-chain portions and it would be nice to simplify it to something that writes the script and policy for you to some extent.

Excellent, that nudge helps a lot. Is my initial intuition about the problem correct (or on the right track). If I implement the policy in a similar way to the Uniswap example can I deploy new contracts in the future that mint the coin in new ways (so long as they still provide the NFT as defined in the initial minting policy?). Just trying to get my design right.

Future-proofing these contracts is going to be a big challenge. I'm sure there are ways to do it, and it sounds like you have some ideas, but Plutus and Cardano SCs are so new that there isn't precedence. You can look at projects on Ethereum which have multiple versions. I think many of them just started from scratch with subsequent versions though. My advice would be to create the minimum version of your contract, even if it won't make it to production, and that will give you a much better idea of what options you have for upgrading.


text:
Can a smart contract read the presence of an NFT in the redeemers wallet?
I want to use an NFT as a form of authentication for a Plutus contract.
I know I can attach the NFT in the Datum when constructing the transaction and return the NFT in the output however I am worried this will "lock" the NFT such that the user can only submit a single transaction.
My use case is an invite mechanism that only holders of a specific NFT are able to execute, this endpoint will generate a UTXO that is used as a required input into the actual signup endpoint.

So based on this example, can the invite endpoint read the presence of the AM NFT in the redeemers wallet without it being sent into the transaction?

Note I am new to a lot of this so feel free to tell me I have got this wrong.

I'd check out using mustSpendPubKeyOutput in your off-chain transaction constraints.
To answer your question directly:

Can a smart contract read the presence of an NFT in the redeemers wallet?

No. A validator script will only validate what's included in a transaction.
But you can include your NFT in the transaction without "lock"ing it. You will want to spend it in the redeeming transaction and return it to the redeemers wallet.
For the transaction to succeed, the validator will  check the UTxOs included in the ScriptContext and if the NFT is included among the values, it will say "yes". The off-chain code could be designed in whatever way that includes the NFT in the transaction, but it sounds like you want to ensure it is returned to the transaction builder's wallet (I'm pretty sure that will be the default behavior if you don't specify a recipient of any UTxOs, but of course check that with tests, etc).


text:
systemd service file for cardano node
i'm trying to run a node as a service using systemctl start node-relay.service
i get this error, can anyone advise what i'm doing wrong.
/home/ec2-user/.local/bin/cardano-node: error while loading shared libraries: libsodium.so.23: cannot open shared object file: No such file or directory
my node-relay.service file looks like this
Description= relay node
After=multi-user.target

[Service]
Type=simple
EnvironmentFile=/home/ec2-user/relay/node.environment
ExecStart=/home/ec2-user/.local/bin/cardano-node run --config $CONFIG --topology $TOPOLOGY --database-path $DBPATH --socket-path $SOCKETPATH --host-addr $HOSTADDR --port $PORT
KillSignal = SIGINT
RestartKillSignal = SIGINT
StandardOutput=journal
StandardError=journal
SyslogIdentifier=cardano-node

LimitNOFILE=32768

Restart=on-failure
RestartSec=15s
WorkingDirectory=~
User=ec2-user
Group=ec2-user

[Install]
WantedBy=multi-user.target

my .bashrc file contains
export LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH"
export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH"
export PATH="~/.local/bin:$PATH"

the node starts fine if it run it like this;
cardano-node run --config ~/relay/testnet-config.json --database-path ~/relay/db --socket-path ~/relay/db/node.socket --host-addr 0.0.0.0 --port 3000

Are you aware of this post: https://forum.cardano.org/t/error-cardano-node-error-while-loading-shared-libraries-libsodium-so-23-cannot-open-shared-object-file-no-such-file-or-directory/39820 ? It refers to another one here https://forum.cardano.org/t/updating-stake-pool-school-config-files/37749/14 which recommends more or less what you did but with an additional step. Worth a try.

The environment variables need to be added to the /home/ec2-user/relay/node.environment file. Or you can specify them directly in node-relay.service file.
[Service]
Type=simple
Environment="LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH"
Environment="PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH"

...

thanks, all makes sense now.


text:
how to convert an "asset32type" to string?
i want to convert an "asset32type" to a string, reason being the datatype in the "name" column of dbsync's multi_asset table is "asset32type".
what is an "asset32type"?

An asset32type is a raw Postgres octet string, but limited to a maximum of 32 bytes. It is defined in schema/migration-1-0004-20201026.sql as:
CREATE DOMAIN asset32type AS bytea CHECK (octet_length (VALUE) <= 32);

eg:
select * from multi_asset limit 3 ;
 id |                           policy                           |         name         |                 fingerprint
----+------------------------------------------------------------+----------------------+----------------------------------------------
  1 | \x00000002df633853f6a47465c9496721d2d5b1291b8398016c0e87ae | \x6e7574636f696e     | asset12h3p5l3nd5y26lr22am7y7ga3vxghkhf57zkhd
  2 | \x3a9241cd79895e3a8d65261b40077d4437ce71e9d7c8c6c00e3f658e | \x4669727374636f696e | asset1aq460y056c3mm4jmuv9vg39n7w8y5gykywjwge
  3 | \x02f68378e37af4545d027d0a9fa5581ac682897a3fc1f6d8f936ed2b | \x4154414441         | asset1tm62f04gz390cjxttq4gz0s43lswr9estr2jcz
(3 rows)

It is stored as a raw Postgres string because there is not guaranetee about the encoding. It might be UTF-8 but it also might not be.

thank you, this makes sense now. i was using convert_from(name, 'UTF8') however it broke for a certain case, the resolve was to use convert_from(name, 'LATIN1') on that record.

The above answer does a great job of explaining what it is, but doesn't answer how you get the value as a string. To pull the value as hex (which is the only thing that makes sense for a policy hash for example), you would encode it like so:
SELECT encode(policy::bytea, 'hex') AS policy_hex FROM multi_asset LIMIT 3;

Likewise, if you want to use a WHERE clause against it, you would decode it:
SELECT * FROM multi_asset WHERE policy = decode('00000002df633853f6a47465c9496721d2d5b1291b8398016c0e87ae', 'hex');

The asset name itself may make sense as ASCII/UTF8 or it might not. There's no guarantees in the system that an asset name resembles anything so should always be treated as raw hex as well and get the actual asset information from the metadata server or metadata on the minting transaction that explains what it actually represents.


text:
cardano-db-sync table link diagram?
Is a diagram showing cardano-db-sync table links available?
i'm aware of the schema.md file, was after something more visual.

There is an Entity Relationship Diagram (ERD) here


text:
How do I properly derive a stake key from an address using Bech32?
I'm trying to get a stake address from a Shelley address in Python using this library: https://pypi.org/project/bech32/
I can convert an address from bech32 to hex without issue, but I'm getting stuck grabbing the staking part (final 56 bytes) and converting that to Bech32. I keep getting a staking address that doesn't actually exist:

address_words = bech32.bech32_decode("addr1qxdvcswn0exwc2vjfr6u6f6qndfhmk94xjrt5tztpelyk4yg83zn9d4vrrtzs98lcl5u5q6mv7ngmg829xxvy3g5ydls7c76wu")

address_hexlist = bech32.convertbits(address_words[1], 5, 16)

account = ''.join([f'{c:04x}' for c in address_hexlist])[-58:-2]

btr = bytes.fromhex(account)

stake_words = bech32.convertbits(btr, 8, 5)

stakeaddr = bech32.bech32_encode("addr", stake_words)
print(stakeaddr)

Using the above, I get the correct account = 883c4532b6ac18d62814ffc7e9ca035b67a68da0ea298cc24514237f
However, I get the wrong staking address at the end: stake13q7y2v4k4svdv2q5llr7njsrtdn6drdqag5cesj9zs3h7xjwn42
The correct staking address should be: stake1uxyrc3fjk6kp343gznlu06w2qddk0f5d5r4znrxzg52zxlclk0hlq
The annoying thing is, the wrong address I get is the same as what you get trying to use https://slowli.github.io/bech32-buffer/ which makes me think I'm missing something specific that cardano does differently to the bech32 spec.
I can't use the provided bech32.exe binary because it refuses to work (even if it did work, I'd still like to get it working in python).

Great first post, welcome aboard.

Credit to someone on Reddit who helped me with this:
Deriving the staking address requires you to manually update the header byte before bech32 encoding the hex account. All I needed to do was add e1 to the start of the account (1110 0001)

Maybe it is a bit late, but hope it helps.
You can use this python library PyCardano to derive the stake key.
Here is the code example:
>>> from pycardano import Address, Network

>>> addr = Address.from_primitive("addr1qxdvcswn0exwc2vjfr6u6f6qndfhmk94xjrt5tztpelyk4yg83zn9d4vrrtzs98lcl5u5q6mv7ngmg829xxvy3g5ydls7c76wu")
>>> addr2 = Address(staking_part=addr.staking_part, network=Network.MAINNET)
>>> addr2
stake1uxyrc3fjk6kp343gznlu06w2qddk0f5d5r4znrxzg52zxlclk0hlq

We first convert the address string to an Address object, addr. Then we use the staking part of the address to create a new stake address.


text:
When is an eUTXO consumed?
Scenario
There are two transactions tx1 and tx2 both trying to consume an arbitrary eUTXo oRef. Both tx1 and tx2 are submitted to the mempool in the same block, and are valid transactions; we can consider them identical for the purpose of the question.
Questions:

When does oRef get consumed? Would oRef exist until the next block?

Would oRef be observable in the same block to a third transaction tx3 which was submitted later than the initial two?

Is there a deterministic mechanism chosing which of the two/three transactions gets accepted?

Some further relevant contextual information transaction events

The question was also answered by a member of the IOHK team, on a secondary channel. I will post the answer here for community reference.
Answer

UTxO entries are consumed "immediately after" the Tx that uses them as an input is validated. That is "after" in the blockchain order. No subsequent transaction in the same block or later blocks can use the oRef input. This is the "no double spend" property, also enforced for Txs in the mempool of any individual node.

The order of execution is inherently non-deterministic. If one Tx is submitted well before the other then the first one is most likely to make it in first. If they are submitted from different points in the network (i.e. by different users) then it is very much non-deterministic which one makes it first. In future there will be limited ways to prioritise, but this example would still depend on timing and be non-deterministic. (The priority mechanism is aimed at ensuring a certain class of latency for inclusion).

Extra information
Txs, disimilar to bitcoin, don't hang around in the mempool for long. The Cardano mempool only acts as a small buffer to smooth out the traffic flow. If the system is saturated, Txs are held at the edge of the network (e.g. in the mempool of on the local node).
So Txs are not in the mempool for long at all. Its behaviour is more like a narrow pipe of fast-flowing water rather than a pool.

Great questions.

When does oRef get consumed? Would oRef exist until the next block?

oRef will be consumed when a transaction spends it. If txn1 is executed before txn2, even in the same block, txn2 will fail. Luckily, the sender of txn2 will not pay a fee for such a failed transaction.

Would oRef be observable in the same block to a third transaction tx3 which was submitted later than the initial two?

No. See above.

Is there a deterministic mechanism choosing which of the two/three transactions gets accepted?

By default, the block builder will just include the transactions in the order they see them. Of course, no one is able to stop the builder from putting them in whichever order they want (or excluding them altogether). This is where the concept of Miner Extractable Value comes from, which is still possible on Cardano.


text:
Daedalus wallet 4.2.0 not syncing
I have a problem with wallet syncing. In fact, the wallet on my imac is not syncing at all. It's not connected to the network. I tried recommendations from a similar post, but nothing worked. I tried to even reinstall the wallet from scratch but it's just not syncing.
When I installed the very same version from the very same installation file on macbook, then there was no problem and the wallet started syncing immediately. But I can't keep the wallet on macbook due to the lack of space.
Any idea why the wallet on imac refuses to sync? It all started with an update to 4.1. version.
Many thanks for your help!


text:
How to permanently persist an arbitrary hash string in the blockchain?
I have an interesting use case for permanently storing an arbitrary hash string somewhere "reliable" publicly and, very important, with a trustworthy timestamp. For me, this sounds like a case for a blockchain application. As I feel a diffuse kind of sympathy for the Cardano project, i thought "why not start here". Let me explain a bit:
The idea is to create a strong hash (SHA2-256 or the like) of arbitrary data (text files, photos, combinations of these, ...). This part is easy. I don't need a blockchain for that and there are many well established standards for doing this. But now I also want to be able to reliably prove, forever, 'til eternity, that this specific hash existed at a certain time.
My first thought was, well, couldn't I just push this hash to a blockchain somehow? I mean, each transaction has a public timestamp that can't be messed with, right? Does Cardano allow for appending metadata like an arbitrary hash string to a transaction? Should I mint an NFT which holds this data? Then again, wouldn't that be overkill for my use case? What are the technical possibilities I could try to work with, here?
I am a developer, but my insights in blockchain technology are quite rudimentary. So I hope that someone can help me out by pointing me in the right direction. Thank you in advance!

Does Cardano allow for appending metadata like an arbitrary hash string to a transaction?

I believe you can do this without needing any tokens/NFTs by just making a transaction that has the metadata attached:
https://developers.cardano.org/docs/transaction-metadata/
This can be done using the --metadata-json-file switch when building the transaction:
cardano-cli transaction build-raw \
  --tx-in dfb99f8f103e56a856e04e087255dbaf402f3801acb71a6baf423a1054d3ccd5#0 \
  --tx-out $(cat payment.addr)+0 \
  --metadata-json-file metadata.json \
  --fee 0 \
  --out-file tx.draft

https://developers.cardano.org/docs/transaction-metadata/how-to-create-a-metadata-transaction-cli#submit-to-blockchain

This is great. TIL.

It really is! Thanks a lot! I wonder how I could miss this reading through the docs...

I'm sure there is more than one way to do this. Tokens can include metadata and depending on what behavior you want you could structure it different ways.
A couple of options come to mind:

Use the Cardano CLI to add hash string to the metadata of a token
Write a smart contract that owns an NFT with the hash string as data

I would first look at the Cardano CLI and see if creating a simple NFT would be good enough for you needs. It's been a minute since I dug into that stuff, so not positive if it will be enough.
If you wanted to do this with a Plutus smart contract, you could have an NFT containing the data owned by the script. This would allow other people, and in theory other smart contracts, to read the hash.
This could look similar to the Oracle Example from the Plutus Pioneers Program. Yours would be simpler because it wouldn't allow the creator to update the value like an oracle.
Essentially it will allow people to consume the hash data on the NFT as long as they return it in the same state they found it. This could also guarantee that you can always find it at the same place, rather than some NFT that could be transferred to different wallets.
Full discretion, this isn't trivial and you'd need to learn how to write/modify the smart contract as well as deploy it. Not to mention, smart contracts are only available on limited test networks as of writing this.
Hope this helps :)

Thank you for your answer, it was helpful in that it added some good ideas to the case. I think you'll understand I accepted the other answer for it's significantly smaller overhead, though :)


text:
Generate random number in Plutus on-chain code
Is it possible to generate a random number in Plutus on-chain code? For example, if I would like to implement a smart contract that works like gambling game, where a person deposits ADA and bets on a random outcome and then the contract generates that random outcome to determine if the player won?

Is it possible to generate a random number in Plutus on-chain code?

No. On-chain code is deterministic, so there is no way to generate a number on-chian that someone off-chain couldn't predict.
The way around this would be to use an RNG oracle. Essentially outsourcing the generation of the random number to some third party, off-chain. You can then use that oracle's (or multiple oracles') data as an input for any games that needs random values.

Thats what I thought. Rather than using an oracle, would it be possible to simulate a RNG by somehow combining data available in UTXOs? If we would require the input transactions to have random datums and then combine them for all UTXOs would that be sufficiently random?

That would create a sort of lottery, where people would be looking for UTxOs that meet a certain requirement, so not exactly an RNG.


text:
Are fees collected for invalid transactions?
Let's say I construct an invalid transaction, that wants to spend UTXOs sitting at a script address and send it to the network for validation. The script then validates the transaction and fails so the UTXOs are not spent. Are fees still collected for such a validation? If not is it a possible vector of attack on the network, to construct millions of such transaction that would make nodes run complex validation scripts?

Generally speaking, you can know whether a transaction will be valid off-chain before submitting it for execution. This is because script validators are deterministic.
There are some exceptions to this however. If you are trying to spend a UTxO that has already been spent, it is possible that your wallet doesn't know that it's spent before it does the off-chain verification. Even in this case you won't have to pay any fees, despite the chain needing to verify something for you.
This is unintuitive to me because this does seem to be a "possible vector" for a DoS attack. However, I don't think the script validator would need to be executed, you could know that it was invalid just by seeing a spent TxO is part of the transaction. Maybe that's the distinction.
I'll try and find the video that explains this and add it here.

Thanks that makes sense. I think that in the case were we want to spend a UTxO that was already spent the validator node will not run the contract script but will reject the transaction right away without any heavy computation. And you are right that usually a transaction is validated off-chain if the user is not malicious. What if somebody would construct invalid transactions on purpose and make the validator node run a complex script that would consume much resources and fail in the end?

I'm beginning to suspect that if a script validator or policy runs, you pay a fee. A non-compliant tx will cause it to fail, but you still pay for the effort. I assume things that are on the tx context, e.g. input TxOs and valid time range, can be checked without running a script validator and thus are "free" to invalidate. I don't know how builtin extrinsics like transfers and staking fit in though. Those cost fees.

A transaction that executes on-chain has costs attached to it, irrespective of the validator succeeding or failing. That's why transactions are test-validated off-chain to avoid this from happening.
And as far as I understand it for a transaction to be considered fir for execution there needs to be some amount of lovelace available to cover costs.
The only overhead I can see - and someone please correct if I am wrong - is in filtering the transaction candidates into a list of transactions fit for execution.

But if the transaction is invalid, no UTXO is spent and the transaction does not make it into the blockchain. If it does not make it into the blockchain then how is the fee collected? As I understand it, the fee has to come from an UTXO.

If your transaction includes TxOs that aren't avaliable, you don't pay a fee. To your point, I guess that's obvious--what would you be paying with?

If your transaction is invalid, it won't be broadcasted to the network. So nothing will happen. This is why Cardano is above ETH. It eliminates bad transactions because its network fees are deterministic.

Plutus code is broken down into on-chain and off-chain code.
The off-chain code is validated in the wallet before being submitted to the network. This allows the smart contract to check things like user signature or deadlines as well as sufficient funds.
The on-chain code actually submits the transactions. The contract can still fail as UTxO's could have changed between the off-chain validation and the on-chain validation, however it is less likely.


text:
I couldn't find the requested endpoint
When I try to construct a transaction by following the Cardano Wallet Backend API (v2021-06-11) (Transaction New section) by writing this code in TypeScript:
const resp: Response = await fetch(`http://localhost:1338/v2/wallets/${senderWalletId}/transactions-construct`, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify({
            payments: {
                address: sendToWalletAdress,
                amount: {
                    quantity: tADAToSend,
                    unit: "lovelace"
                }

            },
        })
    });

I got this response:
{
  message: "I couldn't find the requested endpoint. If the endpoint contains path parameters, please ensure they are well-formed, otherwise I won't be able to route them correctly.",
  code: 'not_found'
}

Is transactions-construct not yet implemented or am I doing something wrong?

Is the senderWalletId correctly formatted?

Yes, but it doesn't even get to that point because /transactions-construct part does not exist

The support for transactions-construct has been added just some days ago and is not released yet.


text:
Plutus Pioneer Cohort 2 Lecture 3
I was going through the lecture on Youtube and this is the one with Vesting example where:

wallet 1 gifts 20 ADA to wallet 2 in 2 different slots
wallet 1 gifts 10 ADA to wallet 3 in a slot
later on, wallets 2 & 3 will grab those gifts after a deadline is passed

So, wallet 1 generates 2 UTXO for wallet 2 to grab & spent. I noticed in the playground that the first UTXO for 10 ADA at script is shown to be spent but the second UTXO is not. But finally, I can see that wallet 2 receives 20 ADA gift in total. Why second UTXO created by wallet 1 to gift wallet 2 is shown unspent although it is spent later on?
Wallet 1 creating gift UTXO for wallet 2 & it is shown spent
Wallet 1 creating gift UTXO for wallet 2 & it is shown unspent
Finally, we can see both UTXO are spent

Unless I'm truly misunderstanding something, this looks like a bug in the playground.

I agree. I think this is a bug in a playground, just needed to make sure.

Please log a github issue for this https://github.com/input-output-hk/plutus-apps
I will make sure it gets followed up on

Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.

I logged a ticket for it in github https://github.com/input-output-hk/plutus-apps/issues/244

Most likely a bug in the playground.


text:
Is there any keyword to get the epoch details or stake-pool details in Plutus Smart Contract?
I am trying to write a smart contract where I can get the awards for delegators of a particular stake pool. I need to know if that is right now possible to do using Plutus, if yes, pls suggest me.

Hey Kuldeep. Welcome to the forum! I made an attempt to answer your questions, but I think I and the other contributors could answer better if you would be more specific with the type of epoch and stake-pool details you are looking for.

Okay. I think you are asking a couple different questions:

Is there any keyword to get the epoch details or stake-pool details in Plutus Smart Contract?

It really depends on what information you need. There are ways for a script to validate certain information about an epoch, e.g. check that the current slot is within a defined epoch.
For example, to check if you are past a deadline in a validator:
from slot `contains` posixTimeRangeToSlotRange (txInfoValidRange (scriptContextTxInfo ctx))

will return True if the transaction takes place after a specified slot. And there are ways to convert an epoch to a slot.
There is also limited staking information in the transaction context.

I am trying to write a smart contract where I can get the awards for delegators of a particular stake pool. I need to know if that is right now possible to do using Plutus

A smart contract can't withdraw awards on behalf of other delegators. The awarded ADA will be only be withdrawable by the wallets that have delegated the funds.
However, it is possible for a script to delegate its own funds. So, depending on the behavior you want, you could have a smart contract delegate on behalf of other delegators and get a similar behavior.
Hope that helps :)

Sorry if the question was put in a confusing way. Is there any way we can know how much a particular delegator earned (ADA) in an epoch from a particular staking pool. This is to be done using Plutus SC. I hope to be clearer this time.


text:
using an output of a transaction in the same transaction
is it possible to implement a plutus script that consumes two UTXO's where the output of one is used as an redeemer for the second?

Not sure if I have it clear, but you can't use outputs of one transaction as inputs in the same transaction because every UTxO is unique and once used, you can't reuse it.
But you can use as many eUTxO's as you want in your transaction. It makes eUTxO model very powerful because you can involve many validator scripts and minting policies in same transaction.

What I would like to do is link contracts, I would guess that this is possible but I do see how the Plutus.tx functions need to be used to implement this. Say is have an script at address 1 that mints an NFT for 10 ada, also consider a script at address 2 which create an action. Then I would like to link these two scripts in one transaction.

Yes, you can do that in the same transaction.


text:
Plutus transaction error PT5
I am building a transaction where I use the following function to make my datum and redeemer,
writeJSON :: PlutusTx.ToData a => FilePath -> a -> IO ()
writeJSON file = LBS.writeFile file . encode . scriptDataToJson ScriptDataJsonDetailedSchema . dataToScriptData . PlutusTx.toData

But when I build a transaction to consume an UTxO at the script address I get the following error,
Command failed: transaction build  Error: The following scripts have execution failures:
the script for transaction input 0 (in the order of the TxIds) failed with:
The Plutus script evaluation failed: An error has occurred:  User error:
The provided Plutus code called 'error'.
Script debugging logs: PT5

I am very certain that my redemeer and datum are correct. My onchain code is the following
data MyDatum = MyDatum
    { pubKey :: Integer
    } deriving (Show, Generic, FromJSON, ToJSON, ToSchema)

data MyRedeemer = MyRedeemer
    { privKey :: Integer
    } deriving (Show, Generic, FromJSON, ToJSON, ToSchema)

data Params = Params
    { params_p :: Integer
    , params_g :: Integer
    , params_bits :: Integer
    } deriving (Generic, FromJSON, ToJSON, ToSchema)

unsafeParams :: Params
unsafeParams = Params p g 64
        where
                p = safePrime64
                g = (safePrime64 - 1) `PlutusTx.Prelude.divide` 2

PlutusTx.makeIsDataIndexed ''MyDatum [('MyDatum, 0)]
PlutusTx.makeLift ''MyDatum
PlutusTx.makeIsDataIndexed ''MyRedeemer [('MyRedeemer, 0)]
PlutusTx.makeLift ''MyRedeemer
PlutusTx.makeLift ''Params

{-# INLINABLE mkValidator #-}
mkValidator :: Params -> MyDatum -> MyRedeemer -> ScriptContext -> Bool
mkValidator (Params p g _) (MyDatum pub) (MyRedeemer priv) _ = pub == exponentiateMod g priv p

Where the the validator checks whether or not the redeemer is the exponent of the datum via modular exponentiation. Perhaps I incorrectly indexed my datum and redeemer with the makeIsdataIndexed function?

Your error means that the validator script returned an error. In the newer version of node, I think 1.33 or 1.34 you can see the exact error message which is thrown from the validator.

I am currently running 1.33, ill update to 1.34 and see what I get there. Thanks for the tip!

PT5 alone means that the validator returned False. You can break down your script into multiple steps of computation and add some traceIfFalse calls along the way to see more context why it happend to be False overall.


text:
How to handle datum in a decentralized way?
What is the best practice of storing the local state of an UTXO to be publicly visible on-chain?
Thinking about how application would function in the future I thought that in a good DeFi ecosystem all datums should be publicly deducible. That is, no intermediate should be needed to process the state. And since the hash function is a one way function there is no deducing what a hashed state represents.
Right now datums can only be send in a transaction as a hashed values right? The cardano-cli only supports building transactions with the command --tx-out-datum-hash. I do not know what the protocol allows at the moment, maybe it is allowed but the client won't construct such transactions for you. Now to overcome this one can send unhashed metadata with the transaction to publicly anounce the datum in the same transaction. I am missing some other way? This extra hashed datum is a bit redundant, though I know it is needed now since UTXO's with empty datums are unclaimable [1].
I think that the SpaceBudz auction contract is initiated in the above described way, metadata is send with every UTXO that is inbound of the script address [2]. I have not figured out how this metadata is correctly formatted to correspond to datumhash. More explicitly, I am yet to construct a json that hashes to the datum via the command cardano-cli transaction hash-script-data --script-data-file file.json.
Lastly I wonder in general what the impact is of these uncompressed metadata transaction. All plutus core code is serialized to hex and is transformed to CBOR before transacting. Would it be a good habit to do this for metadata as well? I have now idea what the PAB will do in this respect, maybe this is a no-brainer?

An other user on the Cardano forum answered this question, for ease of use I'll will post that answer here as well [1].

The protocol allows to embed datum into the witness set, though the current version of the cardano-cli does not support it. What, you can do is download the latest cli build from Hydra and use that one.
Example:
cardano-cli transaction build --tx-out-datum-embed-file ... # or  --tx-out-datum-embed-value
I highly encourage you to use only the precise JSON i.e. -file option instead of the causal one -value one.
But, what do you mean by uncompressed metadata transaction? The metadata in block is serialized from JSON to CBOR.

And

To clear the things a little bit. Datum hash is in the UTxO or as a map key in the witness set.
And yes a datum should not be act like an un-locking thing (that is why there is redeem) and should be publicly available all the time and or easily be reconstructed off chain. They only should be acting as state holders. iirc there was a discussion in the past whether the whole datum should be the part of the UTxO, but they (IOG) have decided not to go with that route for several reasons.
The problem is that in the current implementation the protocol cannot distinguish between the native script addresses (which do not need datum) and the Plutus script addresses, meaning the transaction validator cannot make decision whether an output in its pending/validating transaction requires a datum or not.
Also, keep in mind, due to the nature of UTxO model, everybody can send to any semi valid address (i.e. valid prefix and valid bytes length based on prefix but not existing address e.g, all 0s 0x80000000000....) to anything, which can mean it can be lost forever (or until there is private key generated which can derive that address).


text:
Vim setup of Lars
I was wondering which Vim setup Lars uses in his video, is this perhaps natively available when we use the nix-shell? In lecture two of the third cohort his vim suggests what I guess common used functions, what plugin is this?

I think we can't give exact definition of Lars' Vim configuration, but regarding the intelligent code completion, there are many Vim add-ons that achieve this. coc and Vim Intellisense are two examples.
If you're keen on modding your Vim configuration, you could also check Neovim, which is a fork that "strives to improve the extensibility and maintainability of Vim".

As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.

Take a look at this. After following this guide and setting up the plugins, you will need to nix-shell inside plutus-apps, and then cabal update and cabal build inside the actual haskell code you are trying to use (as Lars explained in the first lecture). That's it, now you can use vim to open your file and, after some time, you will see some cool little colors.
By the way I suggest neovim, because with vim you don't have any idea of what's going on while haskell-language-server is still loading (also neovim is cooler)

It looks like a language server protocol setup (i.e. haskell-language-server). Basically the same as VSCode, but with a different client.

As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.


text:
on multiple eUTxO and the validation proces
I have an in-depth question that needs good knowledge of the ledger rules.
I was thinking about how to program efficiently and design apps such that they are parallelizable, a good practice for achieving this is building modular and piece wise. While thinking about certain contracts that could validate in parallel I wondered how such transactions are build and specified for validation. This is not a canonical task and can be ambiguous for a validator. So a natural conclusion is that to preserve determinism one has to fully specify a transaction, some question on this specification.
Consider a transaction that tries to consume n eUTxO's of contract instance A and m of the contract instance B. Then this transaction has to have n+m datums that match the inputs.
Question 1: Do you specify in your transaction which datum corresponds to which input or does the validator node matches them by hashing your suggested datum? Also, if certain datums match, can you save on transaction size by appending the datum once and specifying the datum to each input?
Question 2: Do you append the contracts A and B multiple time (n+m times to be exact) to the transaction or just once for each occurrence? Again, the latter would save on transaction size.
Now there is also another integral part of consuming eUTxO's, namely their redeemers. Since each eUTxO generally have a different redeemer one also has to specify which redeemer is associated to which input.
Question 3: How is this association between redeemer en input specified in a transaction? And moreover, can this specification again be non-injective. That is, a redeemer can be appended once to the transaction but be associated to multiple inputs? This would again save on transaction size.
And lastly we have the outputs where we give each one a possible new datum. These new datums, how are the specified and can they be assigned in a non-injective way to save on transaction size?

Datums are stored in a hash map per transaction, so if a transaction uses the same datum multiple times, the datum is stored once and only the hashes are stored multiple times. The same goes for redeemers.
(I don't understand all the questions, but this is at least a partial answer. Feel free to add to this answer.)

Thank you Sjoerd, This clears things up about the whole "efficient handling of data" in a transaction of datums. Am I correct that you can extend this hash map idea for the redeemer and script as well?

@Fermat Indeed.

I don't have good knowledge of ledger rules, but I can refer to TxInfo data type in Plutus
data TxInfo = TxInfo
    { txInfoInputs          :: [TxInInfo] -- ^ Transaction inputs
    , txInfoReferenceInputs :: [TxInInfo] -- ^ Transaction reference inputs
    , txInfoOutputs         :: [TxOut] -- ^ Transaction outputs
    , txInfoFee             :: Value -- ^ The fee paid by this transaction.
    , txInfoMint            :: Value -- ^ The 'Value' minted by this transaction.
    , txInfoDCert           :: [DCert] -- ^ Digests of certificates included in this transaction
    , txInfoWdrl            :: Map StakingCredential Integer -- ^ Withdrawals
    , txInfoValidRange      :: POSIXTimeRange -- ^ The valid range for the transaction.
    , txInfoSignatories     :: [PubKeyHash] -- ^ Signatures provided with the transaction, attested that they all signed the tx
    , txInfoRedeemers       :: Map ScriptPurpose Redeemer
    , txInfoData            :: Map DatumHash Datum
    , txInfoId              :: TxId
    -- ^ Hash of the pending transaction (excluding witnesses)
    }

Here you can see that you need to provide Datum only once per each DatumHash, but for outputs, you need to provide a list [TxOut] with DatumHash in each list item. Redeemers should be provided for each UTxO you are trying to spend.
Regarding contracts, you need to attach script only once even if validating multiple UTxOs.
My answers are based on practical experience, so I may be wrong from Ledger perspective.


text:
Referencing (U)TxO's
When Vasil HF is here with the new plutus version, can we only reference unspent transaction outputs or even spent ones? Is there some documentation on these newly added functions? Preferably haddock documentation.

The referencing of UTxO is decribed in the CIP 31 (1). There it is stated that

Referencing an output still requires the output to be presented as
part of the transaction and be unspent, so determinism is preserved.

So no, referencing already spend outputs is not possible to preserve determinism.
On the topic on how these referenced utxo's will be used see the source (2).


text:
What can certificate scripts do?
While looking through the options of the cardano-cli transaction build options I saw the options,
  --certificate-file CERTIFICATEFILE
                           Filepath of the certificate. This encompasses all
                           types of certificates (stake pool certificates, stake
                           key certificates etc). Optionally specify a script
                           witness.
  --certificate-script-file FILE
                           The file containing the script to witness the use of
                           the certificate.
  --certificate-redeemer-cbor-file CBOR FILE
                           The script redeemer, in the given JSON file. The file
                           must follow the special JSON schema for script data.
  --certificate-redeemer-file JSON FILE
                           The script redeemer, in the given JSON file. The file
                           must follow the special JSON schema for script data.
  --certificate-redeemer-value JSON VALUE
                           The script redeemer, in JSON syntax. There is no
                           schema: (almost) any JSON value is supported,
                           including top-level strings and numbers

I was wondering how and what type of scripts are allowed for these certificates? Can we also generate our own type of certificates with plutus? As stated after the --certificate-file flag these entail atleast stake pool certificates and stake key certificates. This would be a good lightweight option for on-chain voting.

I looked at the constructors in the Haddock files of the Certificates in the Plutus.V1.Ledger module. There the datatype DCert is defined as

I am not sure but answering my own question, currently only the above certificates are possible. It is still not clear to me what the --certificate-script-file flag does exactly.


text:
Deploy a local testnet
To test plutus scripts and transactions, I want to have a lightweight environment which I can use when I have no internet. So, how can I deploy a local testnet in the Babbage era for testing?

A local testnet can easily be deployed in the babbage era via the following script in the node repository (1). This method requires you to quickly sequence some commands. This is due to this and failing to launch the stake pools within the 30 seconds will result in not correctly deploying the testnet. I think you can change the 30 start_time yourself to overcome this. The scripts also assumes that the cardano-node and cardano-cli binaries are in your path. Personally, I just enter a nix-shell in the node repository to have these available.
To use this script, you must run it from the cardano-node/ directory via the command
./scripts/babbage/mkfiles.sh

This will create the directory cardano-node/example. In this folder, there are three other scripts that each deploy a stake pool for the testnet (node-spo*.sh). These need to be deployed before the start_time (30 seconds from the mkfiles.sh script execution), so it is good practice to have 3 terminals ready. These node-spo*.sh scripts also need to be executed from the cardano-node/ directory, not the cardano-node/example/ directory. This is because there are some file structures hard-coded in the scripts. To launch the first stake pool, execute the command,
./example/node-spo1.sh

Do the same for node-spo2.sh and node-spo3.sh. The testnet is now running!
The example folder contains the following files. Most notably, you have geneses UTxO keys in the example/utxo-keys/ folder, where the address can be derived via the command,
cardano-cli genesis initial-addr --verification-key-file utxo-keys/utxo1.vkey --testnet-magic 42

.
├── byron-gen-command
│   ├── genesis-keys.000.key
│   ├── genesis-keys.001.key
│   └── genesis-keys.002.key
├── byron.genesis.spec.json
├── configuration.yaml
├── delegate-keys
│   ├── delegate1.counter
│   ├── delegate1.kes.skey
│   ├── delegate1.kes.vkey
│   ├── delegate1.skey
│   ├── delegate1.vkey
│   ├── delegate1.vrf.skey
│   ├── delegate1.vrf.vkey
│   ├── delegate2.counter
│   ├── delegate2.kes.skey
│   ├── delegate2.kes.vkey
│   ├── delegate2.skey
│   ├── delegate2.vkey
│   ├── delegate2.vrf.skey
│   ├── delegate2.vrf.vkey
│   ├── delegate3.counter
│   ├── delegate3.kes.skey
│   ├── delegate3.kes.vkey
│   ├── delegate3.skey
│   ├── delegate3.vkey
│   ├── delegate3.vrf.skey
│   ├── delegate3.vrf.vkey
│   ├── opcert1.cert
│   ├── opcert2.cert
│   └── opcert3.cert
├── genesis
│   ├── byron
│   │   └── genesis.json
│   └── shelley
│       ├── genesis.alonzo.json
│       └── genesis.json
├── genesis.alonzo.spec.json
├── genesis-keys
│   ├── genesis1.skey
│   ├── genesis1.vkey
│   ├── genesis2.skey
│   ├── genesis2.vkey
│   ├── genesis3.skey
│   └── genesis3.vkey
├── genesis.spec.json
├── main.sock -> node-spo1/node.sock
├── node-spo1
│   ├── byron-delegate.key
│   ├── byron-delegation.cert
│   ├── db
│   │   ├── immutable
│   │   │   ├── 00000.chunk
│   │   │   ├── 00000.primary
│   │   │   └── 00000.secondary
│   │   ├── ledger
│   │   ├── lock
│   │   ├── protocolMagicId
│   │   └── volatile
│   │       └── blocks-0.dat
│   ├── kes.skey
│   ├── node.log
│   ├── node.sock
│   ├── opcert.cert
│   ├── port
│   ├── topology.json
│   └── vrf.skey
├── node-spo1.sh
├── node-spo2
│   ├── byron-delegate.key
│   ├── byron-delegation.cert
│   ├── db
│   │   ├── immutable
│   │   │   ├── 00000.chunk
│   │   │   ├── 00000.primary
│   │   │   └── 00000.secondary
│   │   ├── ledger
│   │   ├── lock
│   │   ├── protocolMagicId
│   │   └── volatile
│   │       └── blocks-0.dat
│   ├── kes.skey
│   ├── node.log
│   ├── node.sock
│   ├── opcert.cert
│   ├── port
│   ├── topology.json
│   └── vrf.skey
├── node-spo2.sh
├── node-spo3
│   ├── byron-delegate.key
│   ├── byron-delegation.cert
│   ├── db
│   │   ├── immutable
│   │   │   ├── 00000.chunk
│   │   │   ├── 00000.primary
│   │   │   └── 00000.secondary
│   │   ├── ledger
│   │   ├── lock
│   │   ├── protocolMagicId
│   │   └── volatile
│   │       └── blocks-0.dat
│   ├── kes.skey
│   ├── node.log
│   ├── node.sock
│   ├── opcert.cert
│   ├── port
│   ├── topology.json
│   └── vrf.skey
├── node-spo3.sh
├── pools
│   ├── cold1.skey
│   ├── cold1.vkey
│   ├── cold2.skey
│   ├── cold2.vkey
│   ├── cold3.skey
│   ├── cold3.vkey
│   ├── kes1.vkey
│   ├── kes2.vkey
│   ├── kes3.vkey
│   ├── opcert1.counter
│   ├── opcert2.counter
│   ├── opcert3.counter
│   ├── staking-reward1.skey
│   ├── staking-reward1.vkey
│   ├── staking-reward2.skey
│   ├── staking-reward2.vkey
│   ├── staking-reward3.skey
│   ├── staking-reward3.vkey
│   ├── vrf1.vkey
│   ├── vrf2.vkey
│   └── vrf3.vkey
├── run
│   └── all.sh
├── stake-delegator-keys
│   ├── payment1.skey
│   ├── payment1.vkey
│   ├── payment2.skey
│   ├── payment2.vkey
│   ├── payment3.skey
│   ├── payment3.vkey
│   ├── staking1.skey
│   ├── staking1.vkey
│   ├── staking2.skey
│   ├── staking2.vkey
│   ├── staking3.skey
│   └── staking3.vkey
└── utxo-keys
    ├── utxo1.skey
    ├── utxo1.vkey
    ├── utxo2.skey
    ├── utxo2.vkey
    ├── utxo3.skey
    └── utxo3.vkey

EDIT: Recently the example/run/all.sh has been added to the repo, this lets you run all three example/node-spo*.sh all at once.


text:
Does the hydra node automaticly contest an invalid snapshot?
Given that a participant of a hydra head posts an incorrect (not the latest) snapshot to close the head, does the hydra node automatically contest this? Or do we, the operator of that head, need to use the API to manually contest?

The hydra-node will automatically Contest any transaction it sees on the chain that tries to Close (or Contest!) the head with an invalid or not up-to-date snapshot. There is no need for the operator to do anything, but it might be useful in some scenarios to be able to do so.


text:
How is metadata typed on the blockchain
I am reading through the haddock documentation to find the way metadata is attached to a transaction. In this documentation (1) we have
data Blockchain = [Block]
data Block = [OnChainTx]

Where

and

Now my question is, where and how is metadata appended? My guess is that the only place it could be is in the txData field. And if so, take the example of NFT metadata. By CIP 25 it is of a certain JSON format. Is this than converted via JSON -> data -> BuiltinData and finally wrapped in the Datum type?

I think it just not possible to retrieve metadata from the transaction info that is server into a validator script. Perhaps in the future :)

Also see https://cardano.stackexchange.com/questions/2093/append-metadata-to-transaction-from-plutus-code

The transaction metadata lives outside of the transaction body, inside of the auxiliary_data. In the Babbage ledger era, you can see this in the wire spec (CDDL)
here
In particular, the metadata is defined
here.
In Haskell, you can see that the metadata is
defined
as a map from Word64 to Metadatum.
(I've chosen the Alonzo auxiliary data type to link to here, which is re-used by the Babbage era).
And Metadatum is the JSON-like structure defined
here.

Note that the transaction metadata is a different type than the Datum type used by Plutus, though the structure is nearly identical. (txData contains Datum, not Metadatum.)

CIP-25 is provides a schema for expressing NFT Metadata within the transaction metadata. So in particular, it specifies using the number 721 as the transaction metadatum label ( a reference to the Ethereum NFT standard ERC-721 ), and proceeds to specify the rest of the structure. The cardano-cli is capable of converting JSON metadata files into the correct wire format, and attaching it to a transaction (with the hash in the transaction body, so that it cannot be corrupted).


text:
How to take powers in validator
I was trying to implement some El Gamal cryptography in plutus, basic verification of statements. But while trying to implement an efficient modular exponential function I noticed that the current PlutusTx.Prelude does not even provide a simple power function (^). Digging even deeper I saw that the PlutusTx.Prelude only povides an even function and not even an odd function. How can I contribute to add these function to PlutusTx.Prelude?
Is my implementation correct? I import Plutus.Prelude as Prel. Do I also need to add the template haskell inlinable pragma if I make this a library?
power :: Integer -> Integer -> Integer
power x n |(n==1) = x
        | Prel.even n       = (power x ( Prel.divide n 2))*(pow x ( Prel.divide n 2))
        | Prel.even (n-1)   = x * (power x (n-1))

expMod :: Integer -> Integer -> Integer -> Integer
expMod b e m
    | b == 1    = b
    | e == 0    = 1
    | e == 1    = b `Prel.modulo` m
    | even e    = let p = expMod b (e `Prel.divide` 2) m `Prel.modulo` m
                   in (power p (2::Integer)) `Prel.modulo` m
    | otherwise = (b * expMod b (e-1) m) `Prel.modulo` m

which seems to compile without the pragma in a validator.

Try this function:
power x n
    | n == 0  =  1
    | x == 0  =  0
    | even n = ( power x (n 'div' 2) ) * ( power x (n 'div' 2) )
    | otherwise n = x * ( power x ((n - 1) 'div' 2)) * ( power x ((n - 1) 'div' 2) )

Look at the type signature for even:
even :: (Integral a) => a -> Bool.
odd has a similar signature.
So you can see that even and odd take any type of the Integral typeclass and evaluate it. Then look at the signature for /:
(/) :: (Fractional a) => a -> a -> a.
/ takes only Fractional types, not Integral ones. It's impossible for one type to be evaluated by both those functions. In this case, there's an easy fix: use div instead of /.
Note that if you use div as an infix function (place it between the arguments) you'll need to put backticks around div.

Thank you for correcting my bad cases, but note that the use of odd here is not allowed since PlutusTx.Prelude does not have this.

Well in this case should otherwise (instead of odd) also work, but an odd would be also great.


text:
On the off-chain code of homework 3 cohort 3
I was solving homework1.hs of week 3 of the third cohort and I think there is something wrong with the off-chain code of the solution given the validator. Namely the following, the off-chain part does not specify the end of the txInfoValidRange for the grab endpoint.
I think the current implementation sets this range to [currentTime, Inf]. For the grab of a beneficiary 2 that can grab after the deadline this poses no problem. This since the txInfoRange is contained in the range [deadline, Inf]. But if beneficiary 1 tries to grab before the endpoint the txInfoRange is not contained in the [0, Deadline] since 0 is in general not contained in txInfoRange. This makes that the current proposed solution of the validator can not construct transactions for beneficiary 1 before the deadline?
This can be solved in two ways,

Change the off-chain code to make transactions such that the grab for beneficiary 1 will not fail. How can we set this valid range to before the deadline?
Change the validator (I can not see how one could make this work if we permit the txInfoRange to be indefinite. This because it would also permit beneficiary 1 to collect the vesting funds after the deadline, what we want to avoid.)

I had a similar solution to the solution provided by the IOG acadamy (1) but both of course use the same off-chain code and thus don't work. For example if do the following

Where wallet 1 is beneficiary 1 that can claim after the deadline of slot 10 (POSIXTime = 1596059101000) and wallet 2 with PaymentPubKey 98c77c40ccc536e0d433874dae97d4a0787b10b3bca0dc2e1bdc7be0a544f0ac is beneficiary 2 which can claim the funds before the deadline of slot 10. This emulation in the above screenshot works, wallet 1 can grab the funds. But if we set it up to test if wallet 2 can grab by the following simulation it fails with the following error at slot 6
Add slot 3
Contract instance for W872cb83: (ContractLog (RawJson "made a gift of 50000000 lovelace to 98c77c40ccc536e0d433874dae97d4a0787b10b3bca0dc2e1bdc7be0a544f0ac with deadline POSIXTime {getPOSIXTime = 1596059101000}"))
Add slot 4
Add slot 5
Add slot 6
Contract instance for W7ce812d: (ReceiveEndpointCall (EndpointDescription { getEndpointDescription: "grab" }) (RawJson "{\"contents\":[{\"getEndpointDescription\":\"grab\"},{\"unEndpointValue\":[]}],\"tag\":\"ExposeEndpointResp\"}"))
Contract instance for W7ce812d: (ContractLog (RawJson "found 0 gift(s) to grab"))
Add slot 7

Is my assessment of the off-chain code correct? How can we solve this?

Someone on the IOG discord channel mentioned that this problem arose due to the PubKeyHashes of the wallets being different in this cabal build. I'll do some testing and logging of the PubKeyHashes to check this out.

I found the answer myself. Turns out it has to do with the use of the wrong PubKeyHash in the endpoints. I followed the lecture where Lars used mockWalletPaymentPubKey $ knownWallet 1 to find the PubKey. I used that instead of the hash of this. To get the hash one has to observe the type signature of mockWalletPaymentPubKey $ knownWallet 1 :: PaymentPubKey, I saw in the haddock files that this is just some type wrapper around PubKey, to undo this wrapper simply use its constructor unPaymentPubKey :: PaymentPubKey -> PubKey . Now to hash this PubKey one can use pubKeyHash :: PubKey -> PubKeyHash . So in the end we can easily generate these wallets pubKeyHash's via the following
pubKeyHash $ unPaymentPubKey $ mockWalletPaymentPubKey $ knownWallet 1
a2c20c77887ace1cd986193e4e75babd8993cfd56995cd5cfce609c2

and
pubKeyHash $ unPaymentPubKey $ mockWalletPaymentPubKey $ knownWallet 2
80a4f45b56b88d1139da23bc4c3c75ec6d32943c087f250b86193ca7

Hopes this helps anyone. In conclusion there is nothing wrong with the off-chain code, it was just weird that it validated for grabbing if the deadline past which put me on the wrong track. If anyone knows why this happened, please enlighten me :)

You can also use mockWalletPaymentPubKeyHash $ knownWallet 1, which yields the same result but is shorter


text:
Cardano Development
I am a software developer. I wanted to learn Cardano development so for that where should I start and what technologies are required?

A great place to start is https://developers.cardano.org/.
The page provides a good overview about all Cardano development related topics.
Another great place to get started and learn is the cardano forum: https://forum.cardano.org/
And of course this StackExchange site.

You can join reddit channel for Cardano developers. You can also try to join the Plutus Pioneer Program but Haskell is must for it.


text:
Running Cardano Docker Node
I am working on running the Cardano Node with Docker. I Got it working (running cardano-cli version 1.27.0) but when i execute the following command cardano-cli query tip --mainnet I expect a block result in the era "shelley" bit it shows me I am in the "Byron" era. The epoch parameters returns 'null' instead of a value

How long did you wait before you run the query tip command after starting the node? Your local blockchain first needs to synchronize (download all the blocks). This happens in the order the blocks were produced and can last for several hours.

I waited about 10 seconds. After that it was loaded I think. Do I need to wait longer?

Yes, see my answer.

The behavior you describe is expected. After starting the Docker container, the cardano node will start downloading the whole blockchain. Depending on your system and internet connection it can take several hours to download the whole blockchain.
While the node downloads the blockchain, you can use the cardano-cli query tip --mainnet command to check on the progress. You can compare the current slot of your node with the latest slot (see https://explorer.cardano.org/) to see how much of the blockchain you already downloaded.
As soon as your node has downloaded the whole blockchain you can start to create transactions etc.

This explains it all! I see the block numbers are counting up so the download is working. The next time I run my node again I only have to download the remaining blocks and not the blockchain all over again?

Depends on where you stored the blockchain. Usually it should be stored in a mounted volume that is used by the docker container and is persisted on your drive. In that case you can continue where you left off. If you stored the blockchain data inside of the container, it is probably gone. A volume is mounted by using the -v argument of the docker run command.


text:
Are transaction fee's paid similarly to Bitcoin?
I understand the current staking rewards are a stepping stone to decentralization i.e. by incentivizing users to stake and pools to be set up to secure the Cardano blockchain with the left over Ada similar to the way miners are currently incentivized in Bitcoin with the remaining Btc and in both cases will transition to just Tx fee's in the future.
Currently most staking pools average out to around 5% rewards (equivalent to block reward in Btc). In Bitcoin though the transaction fee's are bundled with the reward and distributed to mining pools. Mining pools then have their own structure on how to distribute those fee's to miners with some distributing all to some keeping those fee's to themselves.
Once smart contracts are live with Cardano and fee's are being paid is the structure similar? Will staking pools have their own transaction fee payout structure? And if so will the busier the network equate to higher the staking rewards?

Once smart contracts are live with Cardano and fee's are being paid is the structure similar?

There are already fees today that have to be paid with every transaction. But there will probably be more transactions and therefore more fees when smart contracts are enabled with the Alonzo hard fork.
That being said, a stake-pool in Cardano works differently than a Bitcoin stake-pool. A Bitcoin stake pool usually lets miners connect to the pool and then everybody tries to find the right nonce for the same block. All the rewards go to the owners of the pool because they own the Bitcoin node that will submit the block when one of the miners has found it.
The proof of stake mechanism on Cardano doesn't require miners. A stake pool is just a single node that produces blocks when it is assigned a block by the network. No race for beeing the fastest to brute force some random number. As an ADA holder you can choose to delegate your ADA to one of the pools. The more ADA is delegated to one pool, the higher the chance that this pool will get a block assigned.
When a Cardano stake pool produces a block, it gets rewards. The rewards consist of the "remaining ADA" and the transaction fees of the transactions in this block. The rewards for this block are distributed among the wallets that are staking with this pool automatically. The pool owner can decide how big of a cut (fixed cost + margin fee) they will keep for themselves. The rest of the rewards are distributed among the delegators according to the size of their stake. This is all done as part of the Cardano protocol and the stake pool operator doesn't have control over the rewards of their delegators.

Will staking pools have their own transaction fee payout structure?

Some pools take 100% of the rewards. Those are called private pools. Binance runs pools like that for the people who want to stake directly from their exchange. The rewards then get distributed by Binance themselves to the accounts of their customers.
There are projects that do something called an ISO (initial stake pool offering) where they take 100% of the rewards and in return pay their delegators in some other token.

And if so will the busier the network equate to higher the staking rewards?

Yes. The more transaction fees a block contains, the higher the rewards.

Perfect answer thank you. I also didn't realize Binance "played middle man" with their stake pool.


text:
How are upgrades implemented in Cardano? CIP's?
Are upgrades to Cardano implemented via Cardano Improvement Protocols like Bitcoin? With the upcoming scaling upgrades such as increasing the block size, pipelining and input endorsers it seems that these upgrades are mainly being performed by IOHK/EMURGO. Are these proposals flagged by nodes/pools as yes/no and a fork created if some pools flag no to the proposal?
My question is concerned with decentralization and how it still seems like few entities are contributing/steering the way for the network compared to Bitcoin where some BIP's caused forks and separate chains because of disagreements on the BIP's.
For example with the block size increase. If there are nodes/pools that disagree with the proposal will we have a Cardano fork like Bitcoin and Bitcoin Cash?

Governance on the Cardano blockchain will come with Voltaire improvements at a a later date. Under the current system, update proposals are controlled by the keys IOG, CF and Emurgo control.
Block sizes are a protocol parameter and require signatures by the above 3 entities to take effect. Participants cannot control from a technical level these parameters; however they can influence them through discussions with the above entities.

I can't find who owns # of keys, and where is it documented?


text:
When will the last ADA be 'mined'
How long until all ada is in circulation? I.e. when will Cardanos circulating supply be 45 billion ada?

Around 2043 the reserve supply will drop below 100 million, meaning most will be in circulation around 2040. Around 2140 the whole reserve supply will be dried up.
You could calculate this yourself, by applying the current monetary policy:

Calculating the 'reserve half life' (that is, the time that it takes
for half of the reserve to be used up) visualizes the impact of
choosing a specific value of ρ over another. This was the subject of
much discussion, and eventually, the value assigned was 0.3%. The
reason why is that mathematical projections showed that a ρ (the fixed
percentage of ada going into the virtual pot every epoch) value of
0.3% would mean a reserve half-life of four to five years. In simple terms, just half of the remaining reserve would be used every four to
five years.
https://docs.cardano.org/explore-cardano/monetary-policy

Other reads:

https://www.linkedin.com/pulse/adanomics-cardano-ada-supply-reserves-rewards-komarovskiy-mba/


text:
(Lecture #6 It #2 - Core.Hs) : Explaining lookups use of both typedValidatorLookups and otherScript?
Can somebody explain these lines and why (both) Constraints.typedValidatorLookups... and
Constraints.otherScript... are used? Still struggling to get my head around lookups, so maybe that is why I'm somehow failing to grasp what exactly the purpose of these lines is and why for example, just the second is not enough by itself?
let lookups = Constraints.unspentOutputs (Map.singleton oref o)     <>
Constraints.typedValidatorLookups (typedValidator oracle) <>
Constraints.otherScript (oracleValidator oracle)```

(Core.hs : lines 169, 170)

This one is a bit technical it has to do with looking up and updating the constraints of an already existing transaction (that belongs to the script address). See Case ii) to skip my synopsis.
Just a little synopsis for future readers: The Core.hs script is an Oracle, that has to update its datum regarding Ada price. The lines in which lookups occur are in the function updateOracle that has the purpose of building a transaction and then submitting it. To accomplish this the constraints need to refer to typed script inputs and outputs. In updateOracle we dealt with two cases
.
.
    case m of
        Nothing -> do
            ledgerTx <- submitTxConstraints (typedOracleValidator oracle) c
            .
            .
        Just (oref, o,  _) -> do
            let lookups = Constraints.unspentOutputs (Map.singleton oref o)     <>
                          Constraints.typedValidatorLookups (typedOracleValidator oracle) <>
                          Constraints.otherScript (oracleValidator oracle)
                tx      = c <> Constraints.mustSpendScriptOutput oref (Redeemer $ PlutusTx.toBuiltinData Update)
            ledgerTx <- submitTxConstraintsWith @Oracling lookups tx
            .
            .

i) Create the Oracle (if it doesn't exists) at the same time of submission and add datum.

ii) Just update the datum of an existing Oracle

Case i) uses submitTxConstraints which takes the constraints as inputs in the form of a script instance (with typed validator hash & the compiled program) and the locked value with the script.
Case ii) on the other hand, uses submitTxConstraintsWith which takes the updated constraints as ScriptLookup type rather than a script instance. To your question, we need to semigroup:

Constraints.typedValidatorLookups (this gets the previous
parameters of the ScriptLookup)
Constraints.unspentOutputs (updates slTxOutputs from
ScriptLookup, which are the unspent outputs that the script wants to
spend)
Constraints.otherScript (updates slOtherScripts from
ScriptLookup, which are validators of the script other than our
script)

The reason why Constraints.typedValidatorLookups alone is not enough is because we would not be updating anything without semigrouping ScriptLookup element by element as defined in OffChain.hs)

What do you mean by "the previous parameters of the ScriptLookup"? Isn't the point of these lines precisely to construct the ScriptLookup?

No, that is handled when case m of -> Nothing for creating the Oracle for the first time. After that we do have initial ScripLookup  parameters.

Wait, so the Scriptlookup "state" is persistent while the (off-chain) contract is running in the wallet? Is that correct? I had understood that we were building everything up from scratch each time for each new transaction, on each pass. And if that is so, then where exacly is this Scriptlookup stored / why is it not lost once we leave the updateOracle function?  As far as I can make out it is not stored on the blockchain... (btw thanks for your answers so far!)

Yes, we build it from scratch the first time, ScriptLookup gives instructions to the wallet on how to create the transaction, and since transactions are unique it lives in the blockchain. Thus, we can access and update it latter on. Updates are only possible through new transactions, these are also build every time but they access to the previous state of the lookups and <> UTXOs out and validators.

I share your confusion around this. I  think a lot of it is due to the flux in the codebase.
On the other hand, I don't think it is anything complicated. The main purpose of Lookups, and thus also those two lines is to supply information needed for the transaction.
I noted that Constraints.otherScript seems to be consistently used where a transaction consumes uTxOs and needs to supply the validator script.
Have a look at Lars explanation in the Iteration #2 Lecture #6 video at 00:50h. In it he mentions that two scripts need to be supplied: one for the input uTxO (consume) and one for output uTxO. This explains why there are two entries, and my guess is that otherScript entry is to be able to consume a script uTxO.


text:
What am I missing here- simple Plutus code from tutorial?
re: https://plutus.readthedocs.io/en/latest/plutus/tutorials/basic-apps.html
Given that the explanation is ""The validator checks that the transaction, represented by scriptContextTxInfo, pays half the specified amount to each recipient.", why does the code not simply use ==half in both cases?
validateSplit :: SplitData -> () -> ScriptContext -> Bool
validateSplit SplitData{recipient1, recipient2, amount} _ ScriptContext{scriptContextTxInfo} =
    let half = Ada.divide amount 2 in
    Ada.fromValue (valuePaidTo scriptContextTxInfo recipient1) >= half &&
    Ada.fromValue (valuePaidTo scriptContextTxInfo recipient2) >= (amount - half)```

Ada is an integer under the hood and divide rounds down.
So, if amount is 5, half would be 2 and (amount - half) would be 3 (totaling to 5).


text:
Stake pool blockchain sync is incredibly slow
Has anyone synced a node lately? It has been 3 days and I've only reached 75% of the tip. This is much slower than a few months ago. I'm currently only connected to the IOHK North America relay with a valency of 3.

This is expected, depending on your hardware, mostly CPU and disk speed, it can take some time.
Cardano mainnet launched about 4 years ago, but just in the last 3 months, the storage taken by the db synced chain has doubled from 30G to 60G.


text:
checkMintedSymbol
What exactly this function is validating?
checkMintedSymbol :: Bool
checkMintedSymbol = case flattenValue (txInfoMint info) of
    [(cs', _, _)] -> cs' == ownCurrencySymbol ctx
    _             -> False

info :: TxInfo
info = scriptContextTxInfo ctx

ctx is a ScriptContext

At first glance, it appears to be some kind of redundancy. But I think it's used to ensure that the CurrencySymbol of the token (or Value) being minted is the same as the CurrencySymbol associated with the Validator/Minting Policy

It validates whether the minted value matches ownCurrencySymbol which in turn is a hash of the validator/minting policy.
The checkMintedSymbol function might be redundant as you cannot mint arbitrary currency without providing matching validator/minting policy.
Edit based on comments: it isn't redundant if there are multiple minting policies in the transaction and it ensures only one kind of currency is being minted.

It's not exactly redundant. It is saying you are only minting one kind (typically you can mint with other policies in the same tx, so in a way this is over-constrained), and it is also saying it doesn't care about the token name (as long as it's all the same) or the amount minted.

Oh, that makes sense now since the validator sees all the mints of the tx not only its "own".


text:
Network.Socket.connect: <socket: 11>: permission denied error accessing node.socket over shared volume mount in docker
I am putting together an application in docker (compose) that has 2 services:

Cardano Node
Web Application

Both services/containers shares the node-ipc via volume mount, when I try query tip via the web application, I am getting permission denied. This is my docker-compose.yml
version: "3.5"

services:

  cardano-node:
    container_name: cardano-node
    image: inputoutput/cardano-node:${CARDANO_NODE_VERSION}
    networks: [ my-app-network ]
    environment:
      - NETWORK=${NETWORK}
      - CARDANO_NODE_SOCKET_PATH=/ipc/node.socket
    volumes:
      - node-db:/data/db
      - node-ipc:/ipc
    logging:
      driver: "json-file"
      options:
        max-size: "200k"
        max-file: "10"

  web-service:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    container_name: web-service
    tty: true
    networks: [ my-app-network ]
    volumes:
      - ../application:/home/web/application
      - node-ipc:/ipc
    environment:
      - CARDANO_NODE_SOCKET_PATH=/ipc/node.socket
    ports: [ "8080:80" ]

volumes:
  node-db:
  node-ipc:

networks:
  my-app-network:

After building the above, I shelled into the web-service container and ran the following:
./bin/cardano-cli query tip --testnet-magic 2

Getting this error:

cardano-cli: Network.Socket.connect: <socket: 11>: permission denied (Permission denied)

I checked the /ipc/node.socket exists via the shared volume mount and I can see it:
web_service@0f78c2f4136e:~/application$ ls -lah /ipc
total 8.0K
drwxr-xr-x 2 root root 4.0K Oct 19 00:13 .
drwxr-xr-x 1 root root 4.0K Oct 19 00:13 ..
srwxr-xr-x 1 root root    0 Oct 19 00:13 node.socket

Any idea why I can't seem to share the node.socket via volume mount?

According to the docs, this should be possible: https://hub.docker.com/r/inputoutput/cardano-node
Mount a volume for establishing cross-container communication via node.socket
docker run -e NETWORK=mainnet -v node-ipc:/ipc inputoutput/cardano-node
docker run -e NETWORK=mainnet -v node-ipc:/ipc inputoutput/some-node-client

The cardano-node inside the docker run as root, and created node.socket as root:
srwxr-xr-x 1 root root    0 Oct 19 00:13 node.socket

HOW TO:
METHOD 1: You can try to change the owner directly, but next time restart the docker compose, it will back to root again.
sudo chown $USER node.socket

METHOD 2: Try to run cardano-node as your user id.
add -u $(id -u ${USER}):$(id -g ${USER}) in docker run command or user: <user id>:<user group> in docker compose
METHOD 3: Remap User ID.
Here is the config guide
https://docs.docker.com/engine/security/userns-remap


text:
transaction build Error: Non-Ada assets are unbalanced (sending native asset to smart contract via cardano-cli 1.34.1)
I have a wallet with the following two UTXOs:

a2e38168473ae7f42e86ac274733004b36a1e119b665a5dae9a799e3a6a9c47a#1 Contains pure ADA balance
942bd39f32524c83973fe3c6b5a9157f6fde5e9b5a30cd6cad8e92145eb2740d#1 Contains multiple native-assets

JSON dump of my wallet UTXO: https://pastebin.com/raw/rVpy9HSk
I would like to send one 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303130 into a smart contract, so I have built the transaction like this:
cardano-cli transaction build \
        --alonzo-era \
        --protocol-params-file tmp/protocol.json \
        --invalid-hereafter 99999999 \
        --out-file tmp/tx.draft \
        --change-address addr_test1qqh04eamdak8x5c5gwxyfxd4uh6cfw2ju3t2ch64an4g3sdzljz3waey7ew4ezg0uvqtrs0rpxuc25w0yptv4ke7z0sqv68nde \
        --tx-in 942bd39f32524c83973fe3c6b5a9157f6fde5e9b5a30cd6cad8e92145eb2740d#1 \
        --tx-in a2e38168473ae7f42e86ac274733004b36a1e119b665a5dae9a799e3a6a9c47a#1 \
        --tx-out="addr_test1wzlvtds2fp3c47p8ut7uumh8splsce70gnqxd8vsk9alcsc92es7p + 1758582 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303130" \
        --tx-out-datum-embed-file create_sale_datum.json \
        --testnet-magic 1097911063

As you can see, I am using using both UTXOs as input and one output (with datum) into SC address - the above results in the following error:

Command failed: transaction build  Error: Non-Ada assets are unbalanced: 129193426 lovelace + 1000 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.436972636c65436f696e + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.546573744c6f6e6744657363 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303035 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303036 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303037 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303039 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303131 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303132 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303133 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303134 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303135 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303136 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303137 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303138 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303139 + 1 9c2f2bd159a50fd8c8ba251c8a488c4ceef42c2cf53c3d7231589f34.57656c6c446f6e65536572696573303230

OS: Ubutunu
Node: 1.34.1 (Testnet)
Any ideas? It looks like it's failing to figure out the change correctly?

The cardano-cli transaction build --help mentions that the order of some options is crucial. In your command can you put --out-file last & --change-address after --tx-out & --testnet-magic after --alonzo-era and give it another crack. This might help --change-address

@MC_Brisbane-JUSTPool I tried changing the order of options as suggested, still returning same error about non-ada asset unbalanced: https://pastebin.com/raw/SDc1zDtV

Thanks for the update. One alternative is to try using build-raw instead of build but this would require you to calculate the fee and include it using --fee . It's not difficult, but is extra steps. Could be a good last resort if no one else is about to help.

Yes I have already planned use build-raw and manually workout the input/output & change. I just wanted to double check I wasn't doing anything silly trying to use the build. It does look like the CLI doesn't seem be able to handle utxo with multiple asset well sadly.

It will be interesting to see if someone has a solid answer to this using build.

Quinn on my team tells me this has always been the case, maybe this is a long overdue upgrade (handle change properly) to the cardano-cli

Good to know, thanks. It might be best to create an answer to your question and accept it. This will help save time for the next person looking for this info.

@Latheesan did you discover the solution?  I am running into the same problem.