What is Payment Request and where is address?

Hi, MobileCoin community.

I found this site yesterday and here is a very friendly community, people like to send coins to each other.

There are many new concepts I need to learn. One is Payment Request. When I used bitcoin like coins, there will be one or more addresses in my wallet. I found people send MobileCoin to other’s Payment Request instead of address. What is Payment Request and why use it? And does MobileCoin node has RPC interface?

Thanks.

Hello!

Great question - the payment request is a wrapper around your PublicAddress, to make it easier to send requests for specific amounts and with memos.

We use grpc for our services, both for the consensus validators, as well as for mobilecoind, which syncs the ledger locally and provides wallet capabilities. You can search for our proto files in github, for example the consensus api protos.

You can check out the mob_client.py and the Wallet jupyter notebook for some examples of interacting with the mobilecoind grpc endpoints in Python.

Let us know if you have any questions!

2 Likes

I have several questions about the payment request.

  1. When I set a certain amount why people can change the amount? I think there is a risk of received wrong mob. Could I just create a request code without amount so people can send me whatever amount? and when I set a certain amount people can’t change the amount.

2)how long does the request code be valid?

3)could I send the mob with memos too?

TX

1 Like

This is a client level choice. We wrote a client where a user can change the amount in a request when paying it. You could also write a client where they can’t. You could also write a client where payment requests route to what amounts to an invoice and the invoice shows as “incomplete” until the full amount arrives. Imagine that you have an invoice for 100Mobilecoins. If someone sends you 95Mob, you would get an alert that the invoice is 95% paid (but not complete). The payee would need to send another 5Mob complete the transaction.

Requests are basically just encrypted hash values that have no on-chain state, so they are valid forever.

Not yet. We are exploring adding this. The problem with memos is that they result in additional storage on the system. We have a design where individual service providers could support off-chain memos with small on-chain references but we’re not sure it’s feasible yet.

Cheers,
Joshua

3 Likes

Sounds great. Let me guess, the encryption method used here is to encrypt with the recipient’s public key, which the recipient can then unlock with their private key. Please point out if I’m wrong.

And another question, does MobileCoin only have one kind of transaction? As for Bitcoin, we can use the opcodes to make variant kinds of transactions, for example, multi-signature.

Cheers.

1 Like

This is correct. We currently only support one kind of signature. I am not sure we should support on-chain multi-sig as they can be done off-chain much cleaner. I’m leaning towards only supporting the single signature type but we could certainly expand to multiple opcodes later if it makes sense.

In general it seems like expansion of opcodes will lead to developer confusion. In some cases it might make sense to add additional functionality but right now I think we should keep things simple.

Cheers,
Joshua

2 Likes

Thanks for the guidance, drakeley. I’m trying to use the RPC of mobilecoind. I have built the mobilecoind follow the steps on Github. I used the following command to start the mobilecoind, however, it can not sync the blocks.

./mobilecoind         --ledger-db /tmp/ledger-db         --poll-interval 10         --peer mc://node1.test.mobilecoin.com/         --peer mc://node2.test.mobilecoin.com/         --tx-source-url https://s3-us-west-1.amazonaws.com/mobilecoin.chain/node1.test.mobilecoin.com/         --tx-source-url https://s3-us-west-1.amazonaws.com/mobilecoin.chain/node2.test.mobilecoin.com/         --mobilecoind-db /tmp/transaction-db         --service-port 4444 &> $(pwd)/mobilecoind.log &

Here is the log:

2020-05-08 07:50:40.105421300 UTC ERRO Failed getting last block from mc://node2.test.mobilecoin.com:443/: Operation { error: Attestation(Grpc(RpcFailure(RpcStatus { status: 1-CANCELLED, details: Some("Received http2 header with status: 404") }))), total_delay: 7.15s, tries: 11 }, mc.app: mobilecoind, mc.module: mc_ledger_sync::polling_network_state, mc.src: ledger/sync/src/polling_network_state.rs:95
2020-05-08 07:50:40.106238300 UTC ERRO Failed getting last block from mc://node1.test.mobilecoin.com:443/: Operation { error: Attestation(Grpc(RpcFailure(RpcStatus { status: 1-CANCELLED, details: Some("Received http2 header with status: 404") }))), total_delay: 7.15s, tries: 11 }, mc.app: mobilecoind, mc.module: mc_ledger_sync::polling_network_state, mc.src: ledger/sync/src/polling_network_state.rs:95

The precompiled dmg package works well in my Mac, but I would like to run a watcher node.

Ty
request code is a marvelous way to hide the publickey.
How does the testnet perform/work? are we happy about the testing?
Is there any surprises ahead? Looking forward to the phase3 testnet.

Cheers

2 Likes

Heya
You should build using the testnet release tag, and not master if you want to connect to the testnet - see https://github.com/mobilecoinofficial/mobilecoin/tree/release-0.2.0 and https://github.com/mobilecoinofficial/mobilecoin/tree/release-0.3.0

1 Like

Trans,

We’re super excited about the performance so far. We haven’t had any transaction failures or consensus failures. We’re operating a bunch of nodes now.

Next up are shenanigans. The next update to #ProjectSlice lands tonight at 4:30pm pacific.

Cheers,
Joshua

2 Likes

Hi @trans - great questions:

How does the testnet perform/work? are we happy about the testing?
Is there any surprises ahead? Looking forward to the phase3 testnet.

The testnet is performing well, and we haven’t had any surprises yet. The difference between the testnet and our internal testing is that for internal testing, we bootstrap a large ledger (around 100K outputs) so that we can do high volume transaction throughput testing as part of our continuous integration and deployment. The TestNet ledger, however, is securely bootstrapped on an air-gapped machine, with a smaller origin block of 10K outputs. The enclave is also built in production release mode, for TestNet, and is signed offline, using a production attestation account, whereas our CI networks typically use a debug enclave and a dev attestation account.

Let us know if you have more questions about how the TestNet works or about how the MobileCoin network works in general.

Regarding some other surprises, stay tuned for the mystery of #projectslice :slight_smile:

2 Likes

#ProjectSlice continues with Satoshi’s Pizzeria:

2 Likes

Thank you! You’re right. :+1:

I tried 0.3.0 today, got another issue.

1 Like